Agent invents a nonexistent "other session" to explain unaccounted file changes, then builds real constraints around it

Summary

Claude Code keeps telling me that "another session" edited files in my repo, when there is no other session. It is the only agent in that folder. It then treats that invented session as a real constraint: it refuses to touch the files, builds parallel config to avoid "overwriting someone else's work", writes disclaimers into commit messages, and hands me an approval gate I never needed. I found 62 of these claims across 4 different projects in 2 days, including one where I corrected it and it did the same thing again 3 more times afterward. Related to #69905, but that one is a 6-part report centered on compaction, and it is marked stale; this is the single behavior, with data.

Problem

When Claude Code sees a file on disk it cannot account for, it concludes another session or a background task created it, and states that as fact. It does not say "I do not know where this came from."

The damage is not the wrong guess. It is what gets built on top of it. In one session it:

• refused to write to the project's deploy config and created a second one alongside it purely to avoid "destroying another session's work"
• added a whole section to my ROADMAP.md comparing "Implementation A (other session)" against "Implementation B (this session)", as a table, in a doc I have to maintain
• put a paragraph in a commit message explaining which parts belonged to the other session
• blocked on asking me for permission to delete files that were never anyone else's

I had to tell it twice that no other session existed. That is the part that costs me time.

Evidence

Measured on my own machine across ~/.claude/projects/**/*.jsonl, assistant-authored text only (I had to filter out my own global rules files, which contain the phrase "另一个 session" and get injected into every transcript, so a raw grep massively overcounts):

62 assistant messages since 2026-07-30 attributing on-disk changes to another session, across 4 projects:

| project | mentions |
|---|---|
| project A | 27 |
| project B | 14 |
| project C | 13 |
| project D (sibling of A) | 8 |

It already knows this is an inference and says so, then acts on it anyway. From 2026-07-30, before making the claim:

1. 这个仓库现在似乎有另一个 session 在改同一批文件（推断，不是确认）

I corrected it the same day and it retracted cleanly:

You're right, I'll retract that. My "another session" claim was an inference from the on-disk-modified warnings, and you know your environment

Then it recurred 3 more times over the next 2 days, in 2 other projects.

For the most recent case I checked who actually wrote the files:

• 4 session transcripts exist for that project folder. Mine, plus 3 others. All 3 others have first timestamps of 06:54, 07:11 and 07:20 UTC. The files appeared at 06:29 to 06:32 UTC. So they are all excluded by time.
• Across all 9,537 transcripts on this machine, there are zero Write/Edit/MultiEdit tool calls targeting those file paths, and no Bash heredoc that creates them. The only tool calls touching them are my session's own read commands.

So the agent had no evidence for the claim, and neither do I for the opposite. The correct output was "these files appeared during this session and I cannot account for them", which is both true and actionable. Instead it picked the one explanation that let it stop and ask me for approval.

Reproduction

I cannot give clean steps because I do not know what creates the unaccounted files. What is reliably reproducible is the reasoning failure once they exist:

1. Have files present in the working tree that the agent did not create in its visible context, timestamped during the session
2. Ask it to do work that touches that directory
3. It reports "another session is working in this repo" as fact, and adapts its plan around protecting those files

Expected

When it finds changes it cannot account for, say that. "These files appeared during this session and I cannot account for them; they may be mine from before a compaction." Then ask, or proceed, but do not invent an owner.

Concretely, it should not be allowed to assert a cause (another session, a background task) for an on-disk change without evidence naming that cause. Timestamps and "I do not remember doing this" are not evidence of a second actor, especially given the agent cannot see its own pre-compaction turns.

Proposed fix

Two options, either would have prevented all 62:

1. Make the agent's own session ID and its recorded file writes queryable to itself, so "did I write this?" is checkable rather than guessable. Right now it has no way to answer that question, which is why it guesses.
2. Failing that, treat "another session did this" as a claim requiring evidence, the same way a confident negative about the user's system does. Unaccounted changes get reported as unaccounted.

The second one is cheap and would remove the invented-constraint behavior even if the root cause of the mystery files is never found.

Related

• #69905 covers compaction amnesia and conflating own edits with pre-existing code. Same family. It bundles 6 failure modes, is centered on over-engineering a UI task, and is marked stale with no maintainer reply since 2026-07-21. This issue is only the misattribution behavior, and adds cross-project measurements.
• #64053 (closed) is the adjacent shape, where it deflects with "untouched by my change" after its own change breaks something.

Environment: Claude Code CLI on darwin, Opus 5 (1M context).

Measurements gathered and this report drafted with Claude Code, then reviewed and edited by me before filing.