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.
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.
This is something I really wish was just built-in to Claude Code. I want it built in because I don't want to have to think about it beforehand. I should be able to jump back in conversation history and have the state of the code jump back with me, so it's restored to the same state it originally was at that point in the conversation.
(There does also need to be a way to jump back in the conversation history without reverting the code, there are times that is useful too!)
Cline gives you the ability to jump back to any point in the task. The three options are "Restore task", "restore files" and "restore task and files"
A common experience with these tools is that if you realize you want to change the direction you're heading, it's better to jump back to that point in the work and redo it than it is to try to redirect the tool from where you are. Here's a great post about it on the Cline blog
Hi, the developer here. Already thinking about a way to add it as a background task that can communicate with multiple instances at once. As long as its part of CLAUDE.md, every new project would have it automatically included. Not part of Claude Code, but a good way closer?
You can press ESC-ESC in Claude code to open the conversation history view and go back to a previous point in the conversation. It doesn't restore code, which is still a miss, but it is built in and useful!
This was a pain point in coming from Aider to CC. How to have diffs of the changes once CC has done the changes? Having git commits done the way Aider does it would have saved me a lot of time.
Actually, the ability to retain the current version when jumping back in conversation history is extremely useful for one reason: trimming context. For example I could work on adding a feature X, which will add some context. Then I rewind and add feature Y, etc. This helps delay compaction.
The claude models are just a part of Claude code. I've worked with both copilot with the Claude models and Claude code itself. Claude code is way more capable, and has a greater likelihood of successfully completing a task.
I tend to have auto-accept on for edits, and once Claude is done with a task I'll just use git to review and stage the changes, sometimes commit them when it's a logical spot for it.
I wouldn't want to have Claude auto-commit everything it does (because I sometimes revert its changes), nor would I want to YOLO it without any git repo... This seems like a nice tool, but for someone who has a very different workflow.
"Checkpoints for Claude Code" use git under the hood, but stored in .claudecheckpoints folder, to not mess with your own git. Add itself to .gitignore.
It auto commits with a git message for the changes done through MCP locally.
As someone who doesn't use CC, auto-commit seems like it would be the easiest way to manage changes. It's easy enough to revert or edit a commit if I don't like what happened.
Yeah I basically have Claude commit via git regularly and the majority of the other features described her can be done via git. I agree it's a neat idea for someone though.
I don't know what this is but isn't git enough? Incidentally I'm not convinced in my day-to-day for "jujitsu" (jj) but from what I understand about how it works, I've been wanting to give it a try for agent-based coding, based on the way it defaults to saving everything and letting you sort it out after. I do like how Aider commits everything so you can easily roll back, although it ends up with a few too many commits imho.
I've been wanting to experiment also with getting an agent to go back and rebase history, rewrite commits etc in the context of where the project ended up, to make a more legible history, but I don't know if that's doable, or even all that useful.
Git won't catch new files the agent is adding. To get around that you can of course always add all new files, but then you'll potentially have your repo polluted with a bunch of temporary scratch files instead.
You can typically go back and edit git history. But it will require force push and breaking changes. And a few sacrifices to ensure that it doesn't make a mistake because then your repo is potentially broken.
Best way to do that is probably to have it work on branches and then squash merge those.
Another problem I inadvertently dodged by using Jujutsu with Claude Code :)
I tend to send a lone "commit" message to Claude when I think I'm in a spot I may want to return to in the future, in case the current path doesn't work out. Then Claude commits it with a decent message. It knows how to use jj well enough for most things. Then it's really easy to jj new back to a previous change and try again.
I always squash and reorganise the commits from aider. It is however awesome that everything is in git directly from the agent. I can’t imagine why not all these tools do this!
I just commit with a “wip!”-prefaced message whenever the LLM pauses and says it’s finished, including new files. You can squash and cleanup later, or revert back to a state before it screwed up.
Also doubles as a way to cohesively look at the changes it made without all the natural language and recursive error/type fixing it does while working.
I don’t understand why people are making it so complicated. You’re saving a minute per iteration with the LLM, tops, at risk of losing control or introducing hard to find issues. It is the definition of diminishing returns.
I don't think jujutsu woild help with this use case -- jujutsu will not save everything because it is not running constantly on your repo. It snapshots the working tree only when you run a `jj` command. Ineffective if an agent is doing work.
I recently started using Aider and had that thought about too many commits. What I realized though was: (1) if I'm going to contribute to a project, I should be working in a local branch and interactively rebasing to clean up my history anyway (and of course carefully reviewing Aider's work first) and (2) if I'm working on my own thing WITHOUT LLM, I tend to prefer to commit every dang little change anyway, I just don't remember to do it because I'm in the zone and then inevitably wish I had at some point.
> I tend to prefer to commit every dang little change anyway, I just don't remember to do it because I'm in the zone and then inevitably wish I had at some point.
That’s what I do too until I developed a practice to break up into thematic commits as I realize I need them. And if I don’t, then I just git reset to the beginning and use git gui to commit lines and chunks that are relevant for a given piece of work. But with experience, I barely do the break down completely - I generally don’t even bother creating commits until I have a starting sense of what the desired commit history should be.
What business? This seems to be completely free, with no pricing, in-app purchases, or anything. That being said, it's strange that it doesn't seem to be open-source.
Yeah this is my problem with building my cathedral up front in a prompt, I just don’t work that way. I need to see some interactions and mess with it to tell how it should work.
T shirt estimation doesn't make any sense for AI dev, not one bit. They get epic long features done in hours, and all the shirt sizing comes from cases where the agent circles the drain and needs to be guided, which isn't predictable.
The shirt sizes now are for manual acceptance testing.
My experience with AI tooling is that while it's really useful and great - I don't think i've ever seen a LLM complete an epic long feature well full stop.
Don't get me wrong, it's definitely improved my workflow and efficiency, but you must be winning at roulette if the model is performing well on anything that can't be googled and implemented witihn a similar amount of time.
unless it's claude, where even simple styling changes seem to become epics just when it wants to spit out an extra few thousands lines of code
> T shirt estimation doesn't make any sense for AI dev
It doesn't make sense for NI (natural intelligence) dev, either. Even SCRUM doesn't make much sense. The only Agile thing that really makes sense is Kanban, which is actually known to computer science as dispatch queue.
In the 60s, OS researchers spent time figuring out how to optimally schedule resources for computation. Today, almost nobody uses these techniques. (This is known as "waterfall" in PM parlance.)
It turns out, the cheapest way to schedule computing resources is a simple dispatch queue. Why spend extra time figuring out in what order things need to be done, or how long they will take, if they need to be done anyway? It never made sense and it doesn't matter whether the agent is NI or AI.
Not to trivialize the work being done here but isn’t this as simple as a hook on edit and write tool calls that commits to git? I’m not sure I see the need for a whole app around this vs just the standard git workflow
Hi, the developer here. Its a very early version so there could be a lot of bugs, but I like to use it myself (already found several bugs and updated version soon on its way).
Switching from Cursor to Claude Code this was the biggest loss. Have tried to improve on the Cursor functionality, with features I missed.
I would love any feedback on what you are missing etc
Hey, so it's a bit obvious you vibe coded this, which makes me not want to trust it. Some red flags:
- The Apple icon is a literal apple and not the Apple logo.
- You've got 2 Mac download buttons that do the same thing right at the top, surely one of those is a mistake.
- "Watch it in action" is positioned poorly and fails to be a header for the video. Too close to the button above it.
- "Automatic version control" is not what a checkpoint is? "Version control" means git to almost everyone.
- Privacy link is a fake placeholder.
- "See It In Action" looks like you meant to add images and just forgot?
- You named this like 5 things. The website title is "Checkpoints for Claude Code", the domain is "Claude Checkpoints", the UI website title is just "Checkpoints" as if its a standalone brand, the contact email link uses "checkpoints-app.com", and finally you call it "Claude Diff" in the App Store description. Oh and the HN submission is a 6th one, "Claude Code Checkpoints".
Readit News
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.
- 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.
Dead Comment
(There does also need to be a way to jump back in the conversation history without reverting the code, there are times that is useful too!)
Ref: https://github.com/google-gemini/gemini-cli/blob/main/docs/c...
A common experience with these tools is that if you realize you want to change the direction you're heading, it's better to jump back to that point in the work and redo it than it is to try to redirect the tool from where you are. Here's a great post about it on the Cline blog
https://cline.bot/blog/how-i-learned-to-stop-course-correcti...
I wouldn't want to have Claude auto-commit everything it does (because I sometimes revert its changes), nor would I want to YOLO it without any git repo... This seems like a nice tool, but for someone who has a very different workflow.
I've been wanting to experiment also with getting an agent to go back and rebase history, rewrite commits etc in the context of where the project ended up, to make a more legible history, but I don't know if that's doable, or even all that useful.
You can typically go back and edit git history. But it will require force push and breaking changes. And a few sacrifices to ensure that it doesn't make a mistake because then your repo is potentially broken.
Best way to do that is probably to have it work on branches and then squash merge those.
Another problem I inadvertently dodged by using Jujutsu with Claude Code :)
I tend to send a lone "commit" message to Claude when I think I'm in a spot I may want to return to in the future, in case the current path doesn't work out. Then Claude commits it with a decent message. It knows how to use jj well enough for most things. Then it's really easy to jj new back to a previous change and try again.
Its fine if you just rebase at the end manually, but not good if you don't, your history will be cluttered and as hard to read as the codebase.
Eventually most people who use coding tools will have low knowledge of what is being generated and then they probably never rebase either...
I just commit with a “wip!”-prefaced message whenever the LLM pauses and says it’s finished, including new files. You can squash and cleanup later, or revert back to a state before it screwed up.
Also doubles as a way to cohesively look at the changes it made without all the natural language and recursive error/type fixing it does while working.
I don’t understand why people are making it so complicated. You’re saving a minute per iteration with the LLM, tops, at risk of losing control or introducing hard to find issues. It is the definition of diminishing returns.
That’s what I do too until I developed a practice to break up into thematic commits as I realize I need them. And if I don’t, then I just git reset to the beginning and use git gui to commit lines and chunks that are relevant for a given piece of work. But with experience, I barely do the break down completely - I generally don’t even bother creating commits until I have a starting sense of what the desired commit history should be.
how long until we start seeing software products for scrum management and t-shirt size estimation for claude code
introduce waterfall methodology to the LLM!
(These people dont realise that there a lot of tradeoffs to be made that pop up during implementation)
The shirt sizes now are for manual acceptance testing.
Don't get me wrong, it's definitely improved my workflow and efficiency, but you must be winning at roulette if the model is performing well on anything that can't be googled and implemented witihn a similar amount of time.
unless it's claude, where even simple styling changes seem to become epics just when it wants to spit out an extra few thousands lines of code
It doesn't make sense for NI (natural intelligence) dev, either. Even SCRUM doesn't make much sense. The only Agile thing that really makes sense is Kanban, which is actually known to computer science as dispatch queue.
In the 60s, OS researchers spent time figuring out how to optimally schedule resources for computation. Today, almost nobody uses these techniques. (This is known as "waterfall" in PM parlance.)
It turns out, the cheapest way to schedule computing resources is a simple dispatch queue. Why spend extra time figuring out in what order things need to be done, or how long they will take, if they need to be done anyway? It never made sense and it doesn't matter whether the agent is NI or AI.
I would love any feedback on what you are missing etc
- The Apple icon is a literal apple and not the Apple logo.
- You've got 2 Mac download buttons that do the same thing right at the top, surely one of those is a mistake.
- "Watch it in action" is positioned poorly and fails to be a header for the video. Too close to the button above it.
- "Automatic version control" is not what a checkpoint is? "Version control" means git to almost everyone.
- Privacy link is a fake placeholder.
- "See It In Action" looks like you meant to add images and just forgot?
- You named this like 5 things. The website title is "Checkpoints for Claude Code", the domain is "Claude Checkpoints", the UI website title is just "Checkpoints" as if its a standalone brand, the contact email link uses "checkpoints-app.com", and finally you call it "Claude Diff" in the App Store description. Oh and the HN submission is a 6th one, "Claude Code Checkpoints".
Cool project though, sorry to be so critical.