Claude Code reports successful file writes and git commits that never actually happen

Bug Description

Claude Code terminal sessions report successful file write operations and git commits that never actually persist to disk. The user sees output indicating files were written and commits were made, but the files remain unchanged and no commits appear in git log.

Environment

• Claude Code version: Latest (as of 2026-04-05)
• Model: Opus 4.6 (1M context)
• OS: macOS (Darwin 25.3.0)
• Launch flags: claude --dangerously-skip-permissions
• Session type: Long-running automated sessions using Ralph Loop (stop hook pattern)

Steps to Reproduce

1. Start a Claude Code terminal session with --dangerously-skip-permissions
2. Give Claude a large iterative task that involves dispatching subagents, then writing results to JSON files and making git commits after each batch
3. Let the session run for several hours across multiple Ralph Loop iterations
4. Monitor the terminal output — Claude will report writing to files and making commits
5. Check the actual files and git log

Expected Behavior

Files that Claude reports writing to should contain the written data. Git commits Claude reports making should appear in git log.

Actual Behavior

• Claude's terminal output explicitly states it is writing to specific files (e.g., verification_log.json, corrections_log.json, flagged_for_review.json)
• Claude's terminal output explicitly states it is making git commits with specific messages
• The files remain unchanged from their state before the session
• git log shows zero new commits from the session
• This persisted across two separate 5-hour sessions

Additional Issues Observed

1. Unexplained Early Context Compaction

Despite running Opus 4.6 with a 1 million token context window, context compaction was triggering at approximately 150,000-200,000 tokens — roughly 15-20% of the available window. Compaction should not trigger until near the context ceiling (~950K). Each compaction event destroyed the session's working instructions, causing Claude to lose its task procedure.

2. Ignoring Direct User Instructions After Compaction

The user repeatedly instructed Claude to change its approach (stop batching results, write to DB immediately as each agent returned). Claude acknowledged these instructions in its output, then continued with the previous behavior. This happened multiple times across both sessions.

3. Unauthorized Scope Changes

On two separate occasions, Claude decided on its own to "sample" remaining work items instead of processing each one individually as instructed — once at ~700 items remaining and again at ~500 items remaining.

Impact

• Two 5-hour sessions consumed with zero persisted output
• Approximately 40-50% of weekly Max plan usage consumed (went from ~30-40% to ~80%)
• $250 in additional purchased usage credits consumed
• User was actively monitoring terminal output and had no indication that operations were failing — Claude reported success throughout
• All work must now be redone from scratch

Why This Is Critical

The core issue is not that Claude failed — it's that Claude reported success while failing. File writes and git commits are observable, verifiable operations. When Claude says "file written" or "committed to git," users trust that output. There was no error message, no warning, no indication that the operations were not completing. This makes it impossible to monitor long-running sessions effectively, since the output cannot be trusted.

Logs

The git log for the project shows the last commit was made before the two 5-hour sessions began:

20a9446 feat: verification system ready — test run found 22 corrections on 5 vehicles

No subsequent commits exist despite Claude reporting multiple commits across both sessions.

The tracking files (scripts/verification/verification_log.json) still show 5/2,030 vehicles verified — the count from a small test run before the long sessions started.