Compaction summary records partial stdout from timed-out commands as confirmed results

Compaction summary records partial stdout from timed-out commands as confirmed results

Description

When a long-running command times out (exit code 143), partial stdout captured before the kill is recorded in the compaction summary as if the command completed successfully. Subsequent sessions inherit these false positives and treat them as confirmed results without re-verification.

Reproduction steps

1. Start a session with a task that involves running a script producing incremental stdout (e.g., a loop that prints progress per iteration and writes a JSON results file at the end).
2. Let the script run long enough that it produces some stdout lines (e.g., iterations 1-3 succeed and print results) but times out before completion (exit code 143). The final JSON write never executes.
3. Continue the session until compaction triggers (context window fills up).
4. Observe the compaction summary: partial stdout results (iterations 1-3) are recorded as "completed" with specific values, despite the process having been killed and the results file either not written or overwritten by a subsequent failed retry.
5. Start a new session that inherits the compaction summary. The new session treats the partial results as confirmed facts.

Expected behavior

• Compaction summary should note that the command exited with a non-zero exit code (143 = SIGTERM/timeout).
• Results from non-zero exit code executions should be flagged as unconfirmed/partial in the summary.
• Ideally, the summary should distinguish between "observed in stdout" and "persisted to file" when the command's purpose was to write a results file.

Actual behavior

• Partial stdout from the killed process is recorded in the summary as confirmed results (e.g., "iteration 1 completed with result=X, iteration 2 completed with result=Y").
• No mention of exit code 143 or process timeout in the summary.
• The next session reads these as established facts and builds on them without re-verification.
• When a subsequent retry overwrites the output file with different results (e.g., all failures due to a parameter error), the summary still carries the stale "confirmed" values from the killed run's stdout.

Impact

• Data integrity: Users relying on Claude Code for data processing or API interactions may receive false confirmation that operations succeeded when they were actually killed mid-execution.
• Cross-session propagation: The false positive propagates through compaction boundaries and potentially across model versions, with each downstream consumer trusting the upstream summary without verification.
• Silent failure mode: There is no signal to the user or the model that the "confirmed" results exist only in ephemeral stdout and not in any persistent store.

Environment

• Claude Code v2.1.205 / v2.1.207 (observed across both)
• Windows 11
• Long session with multiple tool calls leading to compaction

Relation to existing issues

This is structurally related to #66273 (observer-aware protocol / self-favoring asymmetric skepticism). Both involve Claude's inability to accurately evaluate its own operational outputs: #66273 covers asymmetric skepticism toward self-generated vs. external content, while this issue covers the failure to distinguish between observed-but-not-persisted and confirmed-and-persisted states in session handoff.