←back to thread

Claude Code Checkpoints

(claude-checkpoints.com)
184 points punnerud | 5 comments | 28 Aug 25 09:16 UTC | HN request time: 1.04s | source
Show context
slavakurilyak ◴[28 Aug 25 18:44 UTC] No.45055550[source]▶
This looks well-built, but have you considered using Jujutsu (jj) instead? It elegantly solves the snapshot/checkpoint problem without needing MCP servers or a separate app.

With jj, every file change is automatically captured (no manual commits needed), and you can create lightweight "sandbox" revisions for each Claude Code task. When things go wrong, `jj undo` instantly reverts to any previous state. The operation log tracks everything, making it virtually impossible to lose work.

The workflow becomes: let Claude Code generate messy experimental code → use `jj squash`/`jj split` to shape clean commits afterward. You get automatic checkpointing plus powerful history manipulation in one tool.

I've been using jj with Claude Code for months and it's transformed how I work with coding agents - no fear of breaking things because everything is instantly reversible. The MCP integration seems like added complexity when jj's native capabilities already handle the core problem.

For anyone interested in the jj + agent workflow, read my post: https://slavakurilyak.com/posts/use-jujutsu-not-git

That said, respect for shipping something that solves a real pain point! The UI looks clean and the diff viewer is nice.

replies(2): >>45057522 #>>45122462 #
bdangubic ◴[28 Aug 25 21:58 UTC] No.45057522[source]▶
I dont understand the need for this at all. I use the git. Inside one CC session on average there will be 80-160 commits. I can revert back whatever I want whenever I want. Whenever context gets hairy I clear and ask CC to review specific commits to continue or whatever. I must be missing something here completely what is the need for jj at all…
replies(2): >>45058004 #>>45058407 #
1. doritosfan84 ◴[29 Aug 25 00:02 UTC] No.45058407[source]▶
IME, the benefit is ease of branching paths. For example, if I'm working on a feature I can do something like this:

- Put tests in one commit - Tell Claude to come up with several approaches where I'm not exactly sure what the best might be - Put approach 1 into a commit, 2 into a separate one, etc. These approach commits all live side by side instead of stacked on top of each other. - At any point I can create a new commit that is the combination of approach 1 along with the tests and iterate from there - When doing that, I can absorb any changes made into the appropriate commit.

Possibilities kinda open up from there. Maybe intead of fully separate approaches, you just want to break the change into parallel pieces (e.g. you're not sure all of your changes will be needed as requirements change). Then I can create a "super" commit that's the combination of all the other commits even though they're not stacked. That means I can conditionally choose which commits I want to include into my "super" commit too.

replies(2): >>45059981 #>>45072344 #
2. bdangubic ◴[29 Aug 25 03:55 UTC] No.45059981[source]▶
git has worktrees for this, I use them all the time
replies(1): >>45066250 #
3. doritosfan84 ◴[29 Aug 25 16:34 UTC] No.45066250[source]▶
I don't see the correlation. Jujutsu has workspaces as the match to git's worktrees too because their worktrees are a different thing from what I'm talking about. Switching worktrees and making commits is way more work than just making commits.
replies(1): >>45076601 #
4. adastra22 ◴[30 Aug 25 06:21 UTC] No.45072344[source]▶
Lack of staging in jj is a hard pass from me. I usually have a dozen different things I’m working on, and I commit piecemeal whenever one gets across the finish line. How do you do this in jj?
5. bdangubic ◴[30 Aug 25 17:48 UTC] No.45076601{3}[source]▶
“way more” is a stretch to justify introducing another tool like jj into the dev flow