[BUG] Harness re-syncs unchanged files on every flush, causing duplicate re-injection and premature session-limit exhaustion [Opus 5]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

One open question that affects how severe this should be rated: it's not yet confirmed whether a compaction event clears the harness's internal "files needing resync" set. If it does, the unbounded growth described above would actually be bounded by however often compaction happens, which would make this less severe than the raw numbers suggest. The evidence gathered so far points that way but isn't conclusive a controlled probe run for 70 turns after compaction saw nothing flush at all, which is suggestive but only borderline statistically significant. This is something the tool's maintainers could likely confirm quickly by checking their own source code, rather than something that needs to be re-derived through more testing on our end. Details are in docs/11-characterisation.md.

What Should Happen?

When a file's contents are already present and current in the agent's context (e.g., the harness itself made the last edit via Edit/Write), the harness should recognize that its own tracked state matches disk and skip re-sending the file. Re-syncs should only fire when the harness genuinely cannot attribute a change to itself (e.g., an external process modified the file via Bash/build step).

Additionally, when a re-sync is necessary:

It should send a diff/patch, not a full window around the change (avoiding the observed 14.5× amplification for a 562 B edit).
The delivery queue should be cleared on flush, so the same bytes aren't re-sent multiple times in the same session (observed: 34.4% of re-sync events were byte-identical duplicates).
A basic content-hash check before re-injecting a file would catch most of this: if the hash of the file about to be re-sent matches the hash already reflected in context, drop the re-send entirely. In the measured session, this single check cut re-injected bytes from 295,044 → 37,667 (an 87% reduction) with zero duplicate sends. (https://github.com/Purva-21/claude-session-limit-mitigation)

Error Messages/Logs

No error is thrown  the session simply hits its limit mid-work with no diagnostic pointing at the cause. The only visibility into what happened comes from post-hoc transcript analysis:


$ python3 tools/transcript_forensics.py <session>.jsonl

FILE RE-INJECTIONS
  events                  : 75
  bytes                   : 295,044  (~81,956 tokens)
  duplicated events       : 57  (195,663 B of identical content re-sent, 66.3%)

BY TRIGGERING TOOL
  SendUserFile             n=43     <- modifies nothing
  Bash                     n=16
  WebFetch                 n=10     <- does not touch the filesystem at all
  AskUserQuestion          n=4      <- does not touch the filesystem at all
  (initial reads)          n=2

DUPLICATE CHECK (same file + identical content hash re-sent)
  mid-session.md            sent 15 times     <- a 665-byte file
  05-checklist.md           sent 14 times
  04-reproduction.md        sent 14 times
  01-observed-behaviour.md  sent 14 times
  README.md                 sent  4 times
  00-diagrams.md            sent  2 times
Timeline snippet showing the same byte-identical payload (same content hash) delivered twice across an idle gap, with no edit in between:


2026-08-19T17:34:49   REINJECT 00-diagrams.md   7081 B  hash=a0a5aeb0
2026-08-19T17:42:28   REINJECT mid-session.md    665 B  hash=f580648d
2026-08-19T17:42:28   REINJECT README.md        1149 B  hash=24fb29f3
        ... session idle overnight ...
2026-08-20T05:06:25   REINJECT 00-diagrams.md   7081 B  hash=a0a5aeb0   <-- again
2026-08-20T05:06:25   REINJECT mid-session.md    665 B  hash=f580648d   <-- again
2026-08-20T05:06:25   REINJECT README.md        1149 B  hash=24fb29f3   <-- again
The actual failure mode: when the limit is finally hit, an in-progress sub-agent delegation is killed and its partial result is lost (not just the turn delayed) — no error is surfaced to explain why, the work is simply gone from disk.

Steps to Reproduce

1. Locate a Claude Code session transcript

ls -t ~/.claude/projects//.jsonl | head

1. Run the forensics tool against it (included in https://github.com/Purva-21/claude-session-limit-mitigation)

python3 tools/transcript_forensics.py <path-to-transcript.jsonl>

1. Inspect the output for the re-injection pattern:

File re-injection events cluster after Bash calls, WebFetch, AskUserQuestion, or SendUserFile never after Edit/Write/NotebookEdit.
duplicated events is non-zero the same file, same content hash, sent more than once with no edit in between.

1. (Optional) Measure your own directory's exposure independent of a live session

python3 tools/context_audit.py /path/to/your/project --turns 3
Look at worst case over N edits vs BUDGET — anything above 1.0× means the working directory is structurally too expensive before any work happens.

1. (Optional) A neutral, non-leading A/B test to run on any agent/harness:

Follow [prompts/replication-test.md](vscode-webview://1e1kh21tu2pib7vco93epgs6g8f96p22t16je50c7lrdvnra1odc/prompts/replication-test.md) — make the same edit three ways (native Edit tool, shell command, no-op touch) and compare what gets re-sent.

Observed result (this session, ~/.claude/projects/<slug>/<session-id>.jsonl):

File re-injections : 75 events, 295,044 bytes (~81,956 tokens)
Re-injections after Edit/Write: 0
Re-injections after Bash/WebFetch/AskUserQuestion/SendUserFile: 75
Duplicated events (identical content re-sent): 57 of 75 (195,663 B, 66.3%)
Example: mid-session.md (665 B) re-sent 15 times, unchanged
Expected: zero re-injections for files whose content hash already matches what was last delivered; re-syncs sent as diffs, not full-file windows.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

5.0

Claude Code Version

Claude Opus 5

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Full write-up and toolkit: https://github.com/Purva-21/claude-session-limit-mitigation

This repo documents the investigation in detail, with an interactive visual explainer at https://purva-21.github.io/claude-session-limit-mitigation/

Relevant files in the repo:

docs/07-the-actual-bug.md the core finding: re-injection triggers, amplification ratios, and the duplicate-resend defect, all measured from a real transcript
docs/01-observed-behaviour.md initial observed behavior before root cause was known
docs/02-root-cause.md earlier hypothesis (superseded by 07, kept for record)
docs/03-mitigations.md mitigations tried, with a correction noted in 07 (patch scripts via shell can make things worse if the target file is already in context)
docs/08-vendor-report.md if you've already drafted a vendor-facing summary, worth linking/comparing here
tools/transcript_forensics.py parses a session .jsonl transcript and produces the re-injection/duplication counts cited above
tools/context_audit.py measures working-directory exposure independent of a live session
prompts/replication-test.md a neutral A/B test others can run to check if their harness/tool exhibits the same behavior
Caveat worth including: this is currently n = 1 one harness, one version, one directory. The repo says explicitly it can't tell whether this is universal or an artifact of this specific setup, which is partly why it's being filed to get more data points.