You could use a wrapper that parses all the command-line options. Basically you loop over "$@", look for strings starting with '-' and '--', skip those; then look for a non-option argument, store that as a subcommand; then look for for more '-' and '--' options. Once that's all done you have enough to find subcommand "reset", subcommand option "--hard". About 50 lines of shell script.
Sounds like you care about data stored on your filesystem! Take one step back and solve that problem. Use a proper isolated sandbox, e.g. Github workspace on an account that is working with a fork.
Care about the data in that workspace? Push it first.
Othwerwise it is a cat and mouse game of whackamole.
Does any one of this help me if Claude runs `git reset --hard`?
If I am working in a sandbox, I have uncommitted changes in a sandbox and if Claude runs `git reset --hard` on those uncommitted changes in the sandbox, I've got the same problem?
> Care about the data in that workspace? Push it first.
But you're changing the problem. If I push everything, then yeah I've got no problem. But between pushing one change and the next, you're gonna have uncommitted changes, won't you? and if Claude runs `git reset --hard` at that time, same problem, isn't it?
Ok I contest. If you are worried about it resetting it's own work then yes. Although just chuck the same prompt and you should get a similar result amirite? Maybe a better one lol!
Also you can instruct it to commit and push at every step too.
Just fork git and patch that out?
Can't be that hard just ask the agent for that patch.
Don't need to update often either, so it's ok to rebase like twice a year.
