Claude Code Checkpoints

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.

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…

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.