Summary

sessions_spawn can successfully accept a child run while the primary transcript records the tool result as isError: true. Later compaction reads that flag and emits noisy ## Tool Failures entries such as sessions_spawn: failed, even though the payload contains status: "accepted".

Observed behavior

Recent transcripts include toolName: "sessions_spawn", isError: true, and a payload like:

{
  "status": "accepted",
  "childSessionKey": "agent:watcher:subagent:...",
  "runId": "...",
  "mode": "run"
}

The compaction/safeguard layer then mechanically reports those entries as tool failures because it filters on toolResult.isError === true. This makes normal accepted subagent launches look like repeated failures in user-visible summaries.

Expected behavior

• sessions_spawn results with status: "accepted" should be persisted/forwarded with isError: false.
• sessions_spawn results with status: "forbidden" or status: "error" should remain errors.
• Compaction should not amplify older transcripts where accepted spawns were already persisted with isError: true.

Related noise

Shell-like tools also produce noisy failed (no output) summaries when exitCode=1 is expected for probes/no-match cases. That is adjacent, but the immediate regression is the accepted sessions_spawn false positive.

Proposed patch direction

1. Normalize tool result error classification so sessions_spawn + accepted status is not treated as a tool error.
2. Add a compaction guard to skip legacy sessions_spawn accepted payloads already marked isError: true.
3. Add regression tests for both paths.

I am preparing a local patch against main and can follow up with a PR if wanted.