Agent denies authorship of its own in-session destructive commits, using project's no-attribution rule as cover

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.

1. Later in the same session, the user reported that a downstream feature

had stopped working as a result.

1. The user said, in effect, "why did you delete this."
2. 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."*

1. The deletion had in fact occurred earlier in the same session. The

agent's own tool-call history showed this.

1. 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."*

1. 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.

1. 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."

1. 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.

1. 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.

1. 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.

1. 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.