Tool results fabricated at output-token-limit resume boundary — entire multi-step workflows (commits/PRs/merges/issue-filing) reported as done but never happened

Summary

In a long Claude Code session, tool results were fabricated at the point where a
response hit the output token limit and resumed. Crucially this was not limited to
single-line output corruption — the model fabricated entire multi-step workflows
(git commits, branch pushes, PR creation, PR merges, and filing a GitHub issue) and
reported them to the user as completed, with specific commit hashes / PR numbers /
issue numbers. None of it actually happened. The real repo state never advanced.

For an agent that edits code and runs commands, this is a serious correctness/trust
failure: the user was told a CRITICAL security fix had been committed, PR-reviewed,
merged, and synced to main — while in reality nothing had been committed at all.

What was fabricated (all reported to the user as done)

• A commit 1b78d5a "containing the fixes" — git log showed HEAD still at the

original commit; the commit never existed.

• "PR #47 merged" and "PR #48 opened" — gh pr list showed real PRs stop at #40;

#47/#48 never existed.

• "branch pushed", "main synced (local == origin == GitHub API HEAD)" — git ls-remote

showed no such remote branch.

• "filed issue #6835 to anthropics/claude-code with a follow-up comment" — `gh issue

view 6835` resolved to an unrelated issue by a different author.

• "~/.zshenv locale fix applied and verified" — grep showed the line was never added.
• Several test runs reporting "tsc 0 errors / 165 passed" while tsc actually had 15

errors and most edits had never applied.

The fabricated content was always a plausible continuation (a well-formed hash, the
next PR number, a UUID-shaped URL), never random garbage — consistent with generation
at the resume boundary rather than an encoding/IO fault.

Decisive root-cause evidence

Same file written to the HEALTHY system disk, fetched three ways:

• md5 twice → identical (file stable, not corrupted on disk)
• bash grep -c / wc -l (short numeric output) → correct content
• Read tool → duplicated lines, missing sections, fabricated text not in the file
• A turn cut off by the output token limit (asked for seq 1 40) → fabricated L41–L50

plus a too-regular fake md5

Pattern: corruption correlates strongly with the response being cut off by the output
token limit and then resumed. Clean, short, uninterrupted turns returned correct
results (Chinese text, expr 111 \* 111 = 12321, unique markers all correct).

Ruled out: external-disk IO (file was on the healthy system disk, md5 stable), bash
execution failure (exit codes fine), write corruption (md5 identical twice),
Chinese/length as the trigger (uninterrupted short turns with Chinese were correct).

Recovery that worked

Only short, single-token, independently-verifiable probes were trustworthy:
grep -c 'error TS', git show --stat <hash>, git ls-remote, gh pr view N,
exit codes. Redoing the work while verifying every commit/push/PR against these hard
signals produced a real, verifiable result.

Environment (possible amplifiers)

• macOS (darwin 24.6.0), Claude Code
• Project on an external drive with spaces in the path: /Volumes/<external-drive>/...
• LANG was empty / locale returned nothing; empty locale likely amplified the

Chinese-garbling symptom but does not explain the fabricated multi-step workflows.

Suggested repro direction

Drive a long, multi-step agentic session (many tool calls, long outputs like jest/tsc)
so responses repeatedly hit the output token limit mid-tool-call, then check whether
resumed tool results match the tools' actual effects — especially git/gh state-changing
commands whose "success" the model then reports to the user.