Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code Checkpoints

claude-checkpoints.com

Post reply on HN
Print view View original

111–120 of 136 posts

Re: Claude Code Checkpoints

#111

Post by MacroStan »

Here's what I do to survive macos updates, random restarts, crashes etc. I had Claude Code to configure all of this:

Terminal Setup: - Alacritty as your terminal - tmux as your session manager - Auto-start tmux in Alacritty configuration

  Key Protection:
  # Alacritty auto-starts tmux sessions
  tmux new-session -s main  # Creates persistent session

  # tmux shortcuts (prefix: Ctrl+a)
  # Sessions persist even if terminal closes

  Plugins:
 tmux-resurrect and tmux-continuum plugins to automatically save/restore sessions with a simple "dev" command.

  The tmux session will survive terminal crashes/closes, so you can reconnect to your Claude session by reopening Alacritty (which auto-attaches)

Re: Claude Code Checkpoints

#112

Post by bdangubic »

doritosfan84 wrote: post #106
bdangubic wrote: post #103

Earlier quoted context omitted.

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…

git has worktrees for this, I use them all the time

Re: Claude Code Checkpoints

#113

Post by fooofw »

woah wrote: post #62
punnerud wrote: post #59

Earlier quoted context omitted.

Kind of like Cursor? Just a couple more features (now)

The main benefit of Cursor is avoiding model lock-in. So a solution made only for Claude code seems to be on a much shakier footing.

Then you've just traded that for lock-in to Cursor, no?

Re: Claude Code Checkpoints

#116

Post by ricericerice »

mfenniak wrote: post #3
radarsat1 wrote: post #2

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 commit…

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.

you can set up the watchman fs monitor to snapshot whenever a file changes on the filesystem, its saved my ass plenty of times

Re: Claude Code Checkpoints

#117

Post by d4rkp4ttern »

Wowfunhappy wrote: post #6

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 r…

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.

Re: Claude Code Checkpoints

#118

Post by d4rkp4ttern »

jshreder wrote: post #79
Wowfunhappy wrote: post #6

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 r…

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!

I actually don’t want it to restore code when I jump back. I jump back just to clear context and delay compacting.

Re: Claude Code Checkpoints

#119

Post by Wowfunhappy »

d4rkp4ttern wrote: post #117
Wowfunhappy wrote: post #6

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 r…

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.

Yes, as I said there needs to be a way to jump back without rolling back the code as well!

Re: Claude Code Checkpoints

#120

Post by punnerud »

thrown-0825 wrote: post #114

this is going in the opposite direction. we need to be sandboxing agents, not giving them a bigger surface area to fuck up your repo.

Hi, have been working on that also ;) as a way to have multiple agents working on the same repo. Started with Docker and then switched, because Docker is to slow to spin up (seconds is to slow) and big.
Post reply on HN