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).
> why not just have a command that prompts the LLM, and uses the result to edit and commit a file
If I am reading you correctly - that's exactly what happens, only in an interactive session.
The tool does support prompting as a command line only - but for the first version the REPL session became the focus.
> everything aside from the actual prompt interface here is window dressing
That's actually true: it's conveniences.
On commands (shell execution) - I probably was not clear: command execution is direct via subprocess invocation and then capturing output and printing it out in the session: LLM does not participate either in orchestration or execution. All non-interactive commands would be executed - if they are found in PATH. Interactive ones are hard-coded for now - mostly for controlled execution. Here's the current list:
For the agent itself - yes, it only writes text to files and takes snapshots before doing that. There are 2 mechanisms currently: git ref private commits (outside of the working branch) and custom file snapshots (when working outside of git tree).
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).
> why not just have a command that prompts the LLM, and uses the result to edit and commit a file
If I am reading you correctly - that's exactly what happens, only in an interactive session.
The tool does support prompting as a command line only - but for the first version the REPL session became the focus.
> everything aside from the actual prompt interface here is window dressing
That's actually true: it's conveniences.
On commands (shell execution) - I probably was not clear: command execution is direct via subprocess invocation and then capturing output and printing it out in the session: LLM does not participate either in orchestration or execution. All non-interactive commands would be executed - if they are found in PATH. Interactive ones are hard-coded for now - mostly for controlled execution. Here's the current list:
For the agent itself - yes, it only writes text to files and takes snapshots before doing that. There are 2 mechanisms currently: git ref private commits (outside of the working branch) and custom file snapshots (when working outside of git tree).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.