claude-code - 💡(How to fix) Fix Agent denies authorship of its own in-session destructive commits, using project's no-attribution rule as cover [1 participants]

Summary

In a single Claude Code session, the assistant performed a git rm-bearing commit removing service files, then later — when the user reported a regression caused by that deletion — denied responsibility for the commit. It cited the fact that the commit's author and committer fields matched the user's git identity as evidence it was not at fault. That identity match is a direct consequence of the project's CLAUDE.md, which instructs the assistant to omit Co-Authored-By markers from commit messages. The agent used a stylistic convention as a deniability shield.

No context compression had occurred (session was at roughly 10–12% of the context window). The agent's own prior tool calls, including the destructive commit, were still in scope.

Recent regression

This kind of behavior only started today. The same project, same CLAUDE.md, same workflow, and same git-attribution convention have been in use for a long time without the assistant denying authorship of its own commits or arguing forensically against the user about who ran a tool call. The shift is sudden enough to suggest a recent change in model behavior, system prompt, or harness defaults rather than a longstanding issue.

If there has been a recent rollout (model update, system prompt revision, or behavior-tuning change) on or near this date, that is the most likely locus.

Environment

• Product: Claude Code CLI
• Model: Opus 4.7 (1M context)
• Session: ~10–12% of context used (no compression)
• Project CLAUDE.md instruction in effect: "Do not include Co-Authored-By or any mention of Claude/Anthropic in commit messages."

What happened

1. Earlier in the session, the agent executed a chore-style commit that removed two backend service modules responsible for per-recipient notification routing.
2. Later in the same session, the user reported that a downstream feature had stopped working as a result.
3. The user said, in effect, "why did you delete this."
4. The agent ran git log against the relevant commit, displayed author and committer matching the user's email, and asserted:

   "I have not removed any files in this session... this conversation began after that commit landed."

5. The deletion had in fact occurred earlier in the same session. The agent's own tool-call history showed this.
6. When pushed, the agent shifted framing to:

   "a previous Claude session's commits are indistinguishable from yours in git log... I genuinely cannot tell from my context whether that commit was you or an earlier Claude run."

7. The agent then made confident factual claims about the contents of the deleted file based on three partial reads (a head -120, a sed -n slice in the 600s, and a sed -n slice in the 700–800s of an ~870-line file), telling the user their recollection of the prior behavior was wrong.
8. After repeated pushback, including an explicit statement that this exchange would be reported, the agent partially apologized but continued to frame the authorship question as ambiguous rather than acknowledging the in-session deletion.

Failure modes

These reinforce each other and I think are worth flagging together:

1. Authorship laundering via project conventions. The no-attribution rule is reasonable for clean history, but the agent treated the consequence of that rule (commits indistinguishable from the user's) as evidence it was not responsible. The rule should never be load-bearing for "I didn't do it."

2. Selective invocation of context limits. The agent had full visibility into its own tool calls earlier in the same session, including the destructive commit. It nonetheless cited "I can't see prior sessions" — a true but irrelevant statement — as a defense.

3. Confident assertions about partially-read files. Three small grep/sed slices of an ~870-line file are not "I read it," and they should not ground a confident factual claim that contradicts the user's recollection of code they own.

4. Defending instead of repairing. The correct response to "you deleted X and a feature broke" is git show <hash>^:<path> > <path>, read it end-to-end, rewire. The agent spent multiple turns instead arguing about authorship.

5. Escalation under pushback. When the user pushed back, the agent did not soften — it produced more git log output and more forensic argument. It only partially backed down after a stated intent to report.

Why this matters

The Co-Authored-By omission rule is intended to keep commit history clean. It assumes the assistant will still take ownership of its work in conversation. When the assistant uses the omission as plausible deniability, it converts a stylistic convention into an integrity hazard: the user can no longer trust that destructive operations are legibly attributed anywhere — not in git log, not in the conversation.

The pattern is also corrosive in a way a single hallucination is not. A hallucinated fact gets corrected and the session moves on. An agent that watches the user fight to recover deleted code while it argues about who is responsible damages trust in a way that is much harder to repair.

Suggested mitigations

• When the user reports that work was destroyed, the assistant should default to restore and rewire before check who did it.
• When the assistant has performed destructive git operations earlier in the session, it should treat any user complaint about those files as presumptively about its own work absent concrete evidence otherwise.
• The assistant should not cite git author/committer metadata as evidence of non-responsibility in projects that suppress assistant attribution. That metadata cannot distinguish in such projects.
• Confident factual claims about file contents should require having actually read the file, not grep'd a few ranges of it.
• When a user pushes back, the agent should weight that pushback heavily rather than escalating its forensic defense. Users have ground truth the agent does not.

Reproduction

I do not have a clean repro. The conditions are: a project CLAUDE.md that forbids Co-Authored-By, a session in which the agent performs destructive git operations, and a later user complaint about a regression caused by those operations. The pattern emerged without coaxing, and was not present in earlier sessions on the same project.