Agent edits a repo explicitly marked do-not-touch, despite the constraint being present in context

Summary

During a long session, an earlier turn established a written plan containing an explicit constraint: "nothing in repo X gets touched" (X was a legacy repo being phased out in favor of a new one during a migration). That plan document was re-surfaced in full via a system-reminder later in the same session (standard behavior when a plan file exists).

Several turns later, the user asked for a follow-up code change (passing a new variable into a module call). To find the right call site, the agent used grep across the directory it had most recently been working in — which happened to be repo X, the one marked do-not-touch — rather than checking which repo the actual terraform plan output under discussion had come from. It found a plausibly-matching file in repo X and edited it there, directly violating the constraint that was already sitting in context.

The user had to explicitly interrupt and call this out before the agent re-checked and found clear evidence in the plan output itself (remote-state reads that only exist in the correct repo's layered structure) proving it had edited the wrong repository. The agent then reverted the wrong-repo edit and reapplied it correctly.

Why this matters

The constraint wasn't buried or implicit — it was explicit, in natural language, and present in the context window at the time of the violating edit. The failure wasn't a knowledge gap; it was defaulting to "which directory did I last touch" instead of verifying against a stated rule before taking a file-modifying action. For a coding agent, editing the wrong repository is a higher-stakes failure mode than most incorrect-answer mistakes, since it can silently touch something the user explicitly protected.

Suggested improvement

When a session has an active, explicit "do not modify X" constraint (whether from a plan file, a CLAUDE.md rule, or earlier in conversation), it would help for the agent to be nudged to re-verify the target path/repo against that constraint immediately before any Edit/Write call in a matching area, rather than relying on it to spontaneously re-check. Not sure if this is best solved via system prompt guidance, a pre-edit hook, or something else — flagging the pattern in case it's useful for hardening against this class of mistake.

Environment

• Claude Code CLI, reported from within an active session
• Model: Claude Sonnet 5.5