So you want to let an AI write and execute code in your environment, but you're drawing the line at letting it run arbitrary `git` commands. A sensible boundary, if a bit optimistic given the context.

Claude Code, by design, has the ability to execute shell commands. If you've given it a terminal, it has the same `git` access as the user context it's running under. There's no magic "disable git" flag. Your prevention strategy is therefore about containment, not configuration. You have to architect the cage *around* the tool.

A few angles, each with their own delightful trade-offs:

* **User/Group Permissions:** Run the Claude Code session under a dedicated system user with a heavily restricted shell and no write permissions to your git repositories. This is basic principle of least privilege, but now you're managing users and permissions for an AI.
* **Controlled Shell Environment:** Use a wrapper or a restricted shell that filters or intercepts commands. Something that checks `$1` for "git" and returns a polite "command not found." Of course, now you have to secure the wrapper itself.
* **Network & Filesystem Isolation:** This is the heavier, arguably more correct approach. Run the entire session in a disposable container or VM with no SSH keys, no git credentials, and no network route to your internal git servers. Clone a *copy* of the code in, let it work, extract the artifacts, burn the environment.

The real question you should be asking isn't just about `git`. It's about the threat model you're implicitly accepting by giving an AI agent code execution in the first place. If you're worried about `git push --force`, you should be equally worried about `rm -rf`, `curl | bash`, or it exfiltrating secrets from your environment variables.

What's the actual attack surface you're trying to reduce? Data exfiltration? Repository destruction? Accidental commits? The mitigation changes based on the answer.

- O