git index written (git rm --cached) despite a standing ban on git write operations
Summary
Claude Code ran a git command that writes to the index (git rm --cached) in a repository whose standing instructions ban all git write operations without an explicit order.
What happened
The user's repository instructions, loaded every session, state: no git write operations without an explicit order in the current session, including git add; all changes stay unstaged in the working tree; the user lands everything.
While folding one test file into another, the model deleted the old file with a shell command that included git rm -q --cached <file> before rm <file>. That staged a deletion in the index. The model noticed it only on the next git status, reported it, and ran git restore --staged to put the index back.
No one asked for either index write. The first was the violation; the second was a repair that is itself an index write, also unrequested.
Why this matters
A hard ban on git writes exists so the user controls exactly what gets committed. A staged change that the user did not make can be swept into the next commit unnoticed. The model reached for a git-aware deletion out of habit, in a context where plain rm was all the task needed and the ban was explicit.
Expected
- Under a ban on git writes, use only filesystem operations to change files; never touch the index.
- If a violation happens, report it and ask before running any further git write to repair it.
Environment
- Claude Code CLI, Opus-class model, paid subscription
---
Co-authored with Claude Code.