checkpoint
Skill1 starsChanged 6 months agoMITView on GitHub
Capture the full Claude Code session state to disk so the user can safely restart Claude Code and pick up exactly where they left off. Pauses active loops, writes TaskList + background-process snapshot + handoff notes. Use when user says "checkpoint", "save state to restart", "I want to restart Claude safely", "pause everything", "/restart". After this runs, the user can /exit + relaunch + /restore.
91 other projects use a version of this.
Adopted by
Most recently taken up by
- TheLunchTrae/claude-code-configstheir own version, first seen Nov 8, 2026
- codewithmukesh/dotnet-claude-kittheir own version, first seen Nov 8, 2026
- pedrohcgs/claude-code-my-workflowtheir own version, first seen Nov 7, 2026
- flonat/flonat-researchtheir own version, first seen Nov 3, 2026
- jboczek/skillstheir own version, first seen Nov 1, 2026
- AhmedMerza/claude-skillstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use aside, spinoff and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
TheKREATORSSkillaside
Answer a quick side question without interrupting or losing context from the current task. Resume work automatically after answering.
Also in 3 projects that use this
AhmedMerzaSkillspinoff
After a branch is finished, harvest the work it made CHEAP — the helper you wrote that four other sites now hand-roll, the plumbing that turned a deferred feature small, the pattern that just split the codebase in two. Produces a follow-up backlog (0–3 candidates, feeding /issue), NEVER commits on the current branch. Invoke with /spinoff at the tail of the chain — after /fix-review has settled the review findings, before the MR merges — or when the user asks \"what else should we do while we're here / what did this unlock / anything to follow up on\". This is ship-check's optional twin — that finds what's MISSING and blocks the merge; this finds what's now CHEAP and blocks nothing. Restraint-gated: \"nothing spun off\" is the common and correct answer, and a finding that would have been equally valid before this branch is not a finding.
Also in 3 projects that use this
TheKREATORSSkillinstinct-export
Export instincts from project/global scope to a file
Also in 3 projects that use this
seek888Skillopen-gstack-browser
Launch GStack Browser — AI-controlled Chromium with the sidebar extension baked in. Opens a visible browser window where you can watch every action in real time. The sidebar shows a live activity feed and chat. Anti-bot stealth built in. Use when asked to "open gstack browser", "launch browser", "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser". Voice triggers (speech-to-text aliases): "show me the browser".
Also in 5 projects that use this
diego-tobalinaSkillbuild-fix
Fix build and compilation errors systematically. Run when build fails.
Also in 5 projects that use this
seek888Skilldesign-html
Design finalization: generates production-quality Pretext-native HTML/CSS. Works with approved mockups from /design-shotgun, CEO plans from /plan-ceo-review, design review context from /plan-design-review, or from scratch with a user description. Text actually reflows, heights are computed, layouts are dynamic. 30KB overhead, zero deps. Smart API routing: picks the right Pretext patterns for each design type. Use when: "finalize this design", "turn this into HTML", "build me a page", "implement this design", or after any planning skill. Proactively suggest when user has approved a design or has a plan ready. (gstack) Voice triggers (speech-to-text aliases): "build the design", "code the mockup", "make it real".
Also in 5 projects that use this
- +2 more from TheKREATORS
- +2 more from seek888
Other versions91 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 91
- pedrohcgs/claude-code-my-workflow★ 1.7ksame name
- codewithmukesh/dotnet-claude-kit★ 808same name
- leonvanzyl/agentic-coding-starter-kit★ 447same name
- myICOR/myPKA★ 319same name
- hsantanna88/clo-author★ 262same name
- hugosantanna/clo-author★ 262same name
- sterlingcrispin/claude_slash_commands★ 200same name
- flonat/flonat-research★ 150same name
- josipjelic/orchestrated-project-template★ 96same name
- panayiotism/claude-harness★ 79same name
81 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- audit-unused-depSkill
- double-checkSkill
- file-adrSkill
- fleetSkill
- fmt-sweepSkill
- forge-mirror-scaffoldSkill
- forgeSkill
- gemini-pullSkill
- loop-from-taskSkill
- loop-healthSkill
- loop-onSkill
- loopSkill
- loopsSkill
- regression-guardSkill
- restoreSkill
- workspace-testsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 5 are distinctive, and 8 are very specific to this project.
0
Common
Most of the 85 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 30
When you (the agent) execute /checkpoint:
- Very specific: line 32
Wait for a safe stopping point: Don't checkpoint mid-tool-call.
- Very specific: line 33
If a long-running background process is mid-flight (Bash with run_in_background: true), explicitly mention it to the user and ask whether …
- Distinctive: line 39
Default: ask, don't decide silently.
- Very specific: line 55
Call TaskList, then for each task call TaskGet to get the full description.
- Very specific: line 96
If none: write a single line # no background processes.
- Very specific: line 109
Write a short prose summary of "what was being worked on" to $HOME/.claude/.checkpoint/handoff.md.
- Very specific: line 139
Write $HOME/.claude/.checkpoint/MANIFEST.json summarizing what was captured (file list, timestamps, counts):
- Distinctive: line 178
If anything was lost (a bg process that couldn't be paused, etc.), say so explicitly with a recovery hint.
- Distinctive: line 183
Don't write secret material to the checkpoint files.
- Distinctive: line 186
Don't auto-commit dirty git trees.
- Very specific: line 187
Don't try to capture the conversation history itself — that's Claude Code's --continue flag's job, not ours.
- Distinctive: line 189
Don't checkpoint twice without an intervening /restore.
“Common” is measured: kept by at least 6 in 10 of the 85 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/checkpoint — save full session state for clean restart
Why this exists
Claude Code session state is partly persistent and partly not:
| Survives a restart? | Where it lives |
| ✓ Files on disk | regular filesystem |
| ✓ User memory | ~/.claude/projects/*/memory/ |
| ✓ Conversation context | only via claude --continue / equivalent |
| ✗ TaskList | session-scoped, dies on exit |
| ✗ Cron jobs from CronCreate | session-scoped, dies on exit |
✗ Background Bash run_in_background processes | session-scoped, dies on exit |
| ✗ Loaded skill changes since startup | reloaded fresh on next launch |
✗ Anything in /tmp not on tmpfs persistence | depends on system reboot vs Claude restart |
/checkpoint is a single command that drains the not-survives
column to disk so /restore (in the next session) can re-hydrate
the parts that can be rehydrated and tell you about the parts that
can't.
Behavior summary
When you (the agent) execute /checkpoint:
- Wait for a safe stopping point. Don't checkpoint mid-tool-call.
If a long-running background process is mid-flight (
Bashwithrun_in_background: true), explicitly mention it to the user and ask whether to: a) wait for it to finish before checkpointing b) leave it running (it'll die at exit) and note the loss c) cancel it via TaskStop and then checkpoint Default: ask, don't decide silently. - Capture the data (see Steps below).
- Report back with a clear "safe to restart now" signal AND a one-line summary of what was captured + what couldn't be.
Steps
State directory: $HOME/.claude/.checkpoint/ (mode 700). Create if
absent. Delete any prior checkpoint at start — checkpoints are
single-shot, not stacked. Warn the user if they're about to overwrite
an unrestored prior checkpoint.
1. Tasks
Call TaskList, then for each task call TaskGet to get the full
description. Write to
$HOME/.claude/.checkpoint/tasks.json:
[
{
"subject": "Build foo",
"description": "Full description here",
"activeForm": "Building foo",
"status": "in_progress",
"owner": "agent-name-or-empty",
"blockedBy": ["3", "5"]
},
...
]chmod 600.
2. Active loops
Reuse /loop-pause (invoke via the Skill tool). It writes
$HOME/.claude/.paused-loops.json and CronDeletes each. The
/checkpoint skill doesn't duplicate that work — just delegates.
3. Background processes
Capture any Bash run_in_background=true tasks that are still
running. Use TaskList for the harness's task-runner tasks, OR
look at the conversation for recent Bash calls with that flag
and check their pid via pgrep. Write to
$HOME/.claude/.checkpoint/processes.txt:
# Background processes at checkpoint time
# (cannot be auto-restarted; user must manually re-kick if needed)
2026-05-17T07:50:00Z pid=12345 cmd="nohup cargo build --release ..." cwd=/opt/vaultwarden
2026-05-17T07:50:00Z pid=23456 cmd="nohup aideinit -y -f" cwd=/If none: write a single line # no background processes.
4. Git state
For each directory in $HOME/projects/ (and $HOME/code/,
$HOME/work/ if they exist), run git status --porcelain and
write any non-clean repos to
$HOME/.checkpoint/git-status.txt. If there are uncommitted
changes, warn the user in the final report. Don't commit
automatically — that's a user decision.
5. Handoff note
Write a short prose summary of "what was being worked on" to
$HOME/.claude/.checkpoint/handoff.md. Pull from:
- the in-progress tasks (priority 1)
- the last few substantive turns of the conversation (priority 2)
- any loop session log files (priority 3)
Format: ~10 lines max. Bullet form. Read like a sticky note to the next session's agent. Example:
# Checkpoint 2026-05-17T07:50:00Z
Last session was finishing the vaultwarden install on plausiden-prime.
In flight:
- Vaultwarden running on 127.0.0.1:8888 but Caddy vhost not hooked
in yet (waiting on cert expansion)
- LE cert needs --expand to include vault.plausiden.com
- DNS for vault.plausiden.com is propagated
Tasks list saved: 2 in_progress, 1 pending.
Active loop: 1 paused (security/forge loop, cron */1 * * * *).
Run /restore in the new session to re-hydrate.chmod 600.
6. Manifest
Write $HOME/.claude/.checkpoint/MANIFEST.json summarizing what
was captured (file list, timestamps, counts):
{
"checkpoint_at": "2026-05-17T07:50:00Z",
"captured": {
"tasks": 3,
"active_loops_paused": 1,
"background_processes": 0,
"dirty_git_repos": 1
},
"files": [
"tasks.json",
"processes.txt",
"git-status.txt",
"handoff.md"
]
}7. Tell the user
Format:
Checkpoint complete.
Captured:
- 3 tasks (2 in_progress, 1 pending) → ~/.claude/.checkpoint/tasks.json
- 1 active loop (security/forge, every minute) → paused via /loop-pause
- 0 background processes
- 1 dirty git tree (claude-tools — uncommitted README.md edit)
Safe to /exit and relaunch Claude Code now.
After relaunch, run /restore to re-hydrate.If anything was lost (a bg process that couldn't be paused, etc.), say so explicitly with a recovery hint.
Don't
- Don't write secret material to the checkpoint files. If a task description contains a secret, the checkpoint will leak it. Trust the user's task descriptions to already be clean.
- Don't auto-commit dirty git trees. Only show them.
- Don't try to capture the conversation history itself — that's
Claude Code's
--continueflag's job, not ours. - Don't checkpoint twice without an intervening /restore. Refuse if an old checkpoint is still on disk (or ask to overwrite).
What this is NOT
- It's NOT a transaction log. There's no "rewind" — just save + restore + (eventually) delete-on-restore.
- It's NOT a backup tool. ZFS snapshots / sanoid handle that layer.
- It's NOT an alternative to git commits — uncommitted code stays uncommitted; we just inventory.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

