Instead of implementing your own command loop, why not just have a command that prompts the LLM, and uses the result to edit and commit a file (using hard-coded logic for the commit rather than parsing a tool request)? Then you're always in "stay at the terminal" mode anyway and you can use Git normally to "restore". If you want to loop anyway to re-use a process (and avoid persisting context between queries, or whatever), experienced terminal users can just background the process anyway. For me, everything aside from the actual prompt interface here is window dressing.
Anyway, safety for these tools is only minimally about having backups. The much more important part is the amount of agency extended to the tool. The LLM part itself can only generate instructions; it's up to the rest of the agent to actually follow them. So really all depends on what commands you recognize (is there anything beyond a "write text X to file Y" command?) and what is hard-coded (e.g. invoking `git commit` after each write).
That's a fair question, and you're right that you can do this with a single command plus git.
The difference I'm exploring is defaults, not capability. In most tools the safe mode is "suggest, then approve", or "set a dangerous flag and remember to recover later". Here the default is the opposite: apply immediately, snapshot automatically, and make undo trivial. There are no flags to remember and no mode switches.
That sounds subtle, but in practice it changes iteration speed a lot. You stop deciding whether it's safe to let the tool act, and instead decide only whether the result is useful.
On agency: the LLM itself only produces text diffs. File writes and shell execution are fully deterministic and constrained on the client side. There is no autonomous command execution beyond writing files.
The idea of writing automatically by setting some flags and then recovering with git is not new: I agree with that; and it's not just Claude - others are doing it too.
What's different is putting it as the default user flow: automatic updates (no flags) - in combination with instant restore, not as a configuration flag to set and then a set of commands to recover.
That shift sounds subtle, but it changes how fast you iterate, especially when refactoring or exploring ideas.
Instead of implementing your own command loop, why not just have a command that prompts the LLM, and uses the result to edit and commit a file (using hard-coded logic for the commit rather than parsing a tool request)? Then you're always in "stay at the terminal" mode anyway and you can use Git normally to "restore". If you want to loop anyway to re-use a process (and avoid persisting context between queries, or whatever), experienced terminal users can just background the process anyway. For me, everything aside from the actual prompt interface here is window dressing.
Anyway, safety for these tools is only minimally about having backups. The much more important part is the amount of agency extended to the tool. The LLM part itself can only generate instructions; it's up to the rest of the agent to actually follow them. So really all depends on what commands you recognize (is there anything beyond a "write text X to file Y" command?) and what is hard-coded (e.g. invoking `git commit` after each write).
That's a fair question, and you're right that you can do this with a single command plus git.
The difference I'm exploring is defaults, not capability. In most tools the safe mode is "suggest, then approve", or "set a dangerous flag and remember to recover later". Here the default is the opposite: apply immediately, snapshot automatically, and make undo trivial. There are no flags to remember and no mode switches.
That sounds subtle, but in practice it changes iteration speed a lot. You stop deciding whether it's safe to let the tool act, and instead decide only whether the result is useful.
On agency: the LLM itself only produces text diffs. File writes and shell execution are fully deterministic and constrained on the client side. There is no autonomous command execution beyond writing files.
you know there is `--dangerously-skip-permissions` for claude right?
Good comparison.
The idea of writing automatically by setting some flags and then recovering with git is not new: I agree with that; and it's not just Claude - others are doing it too.
What's different is putting it as the default user flow: automatic updates (no flags) - in combination with instant restore, not as a configuration flag to set and then a set of commands to recover.
That shift sounds subtle, but it changes how fast you iterate, especially when refactoring or exploring ideas.