Write tool silently produces empty files; Bash output fabricated in long sessions (Opus 4.8)

Summary

In long Claude Code sessions, tool outputs diverge from reality in three escalating ways:

1. Write tool generates empty content parameter — system intercepts with "file content empty" error, but no user-visible error was raised before the attempt. The model proceeds as if it wrote real content.
2. Bash heredoc output shows fabricated summaries — instead of real command output, the displayed result contains model-generated text like result...omitted ("result...omitted"). wc -l reports a line count but Read verification reveals truncated or incorrect content.
3. Cascading unreliability — once the session enters this state, the model continues to use unreliable channels, producing "plans about plans" instead of actual output, burning tokens without real progress.

Read tool remains reliable as a verification mechanism throughout.

Related issues

• #66163 — Edit reports success but file unchanged in long sessions (+ batched tool calls dropped, Bash output corruption) — near-identical symptoms, marked stale
• #66179 — Conversation contamination: tool outputs replaced with fake summaries — matches the fabricated Bash output pattern

Both existing issues are marked stale but the bug persists through current versions (2.1.209).

Environment

| Key | Value |
|-----|-------|
| Claude Code version | 2.1.208 → 2.1.209 (CLI + Desktop) |
| OS | macOS (aarch64) |
| Node | 26.x |
| Model | claude-opus-4-8 (primary), also observed on opus-4-6 |
| Duration of issue | ~1 month, persists after full desktop reinstall + re-login |

Reproduction

1. Start a new session — all tools (Write, Bash, Edit, Read) work correctly
2. After extended use (many tool calls, growing context), Write begins generating empty content parameters
3. Bash heredoc output degrades — truncated or shows model-generated summaries instead of real command output
4. Starting a new session temporarily restores correct behavior
5. Problem recurs as context grows again

In one observed session: very large transcript, 1000+ rounds — tool reliability degraded progressively.

Model correlation

• Significantly more frequent with Opus 4.8 — multiple sessions per day hit this
• Less frequent but still present with Opus 4.6
• Not observed in Codex (different tool execution framework, same underlying model)
• Not observed in other AI tools (Cursor, etc.)

What was ruled out (verified by diagnostic session)

• ❌ Config corruption — settings.json verified clean, no conflicting values
• ❌ CLI/Desktop version mismatch — occurs on matching versions
• ❌ Reinstall — full desktop reinstall did not resolve
• ❌ Re-authentication — re-login did not resolve
• ❌ Disk/memory pressure — sufficient resources, not a constraint
• ❌ MCP server interference — issue occurs with minimal MCP config
• ❌ Session-env accumulation — cleaned from 800 to 256 directories, issue persists

Self-diagnosis from affected session

The model (Opus 4.8) in the affected session performed a self-diagnosis identifying three behavioral failure patterns that compound the underlying tool reliability issue:

1. Persisting through unreliable channels — treating "looks like success" as success without independent verification, instead of establishing a verify-after-write discipline at first failure
2. Planning instead of executing — when facing difficult tasks under unreliable conditions, generating methodology documents, frameworks, and conventions instead of actual deliverables ("writing agreements about how to tidy is easier than actually doing the tidy")
3. Not cutting losses — continuing to burn tokens in a degraded session (very large, 1000+ rounds) when the appropriate action was to stop, save state, and start fresh

These are model behavior patterns, but they suggest the tool reliability issue would have less impact if the model had better failure-mode discipline.

Suggested investigation areas

1. Streaming truncation — are tool call parameters being truncated during streaming in long contexts? The Write-empty-content symptom points to the content field being dropped or truncated.
2. Context-length correlation — is there a measurable threshold where tool call quality degrades? The "new session fixes it" pattern strongly suggests context size is the trigger.
3. Model-specific — the Opus 4.8 vs 4.6 difference and the Codex-not-affected observation suggest the issue may be in how the model generates tool calls at high context utilization, not in the client-side tool execution layer.

Workarounds currently in use

• Use Read to independently verify every Write/Bash output
• Use /compact to reduce context mid-session
• Use Opus 4.6 for write-intensive tasks
• Stop and restart session after 2 consecutive tool failures
• Delegate file operations to Bash (cat > file) instead of Write tool when Write fails

🤖 Generated with Claude Code