Background compaction can lose a completed parallel GPT tool result and cause HTTP 400

[koboldul]

Describe the bug

In Copilot CLI 1.0.80, a long-context gpt-5.6-sol autopilot session can fail immediately after automatic background compaction with:

CAPIError: 400 No tool output found for function call call_<redacted>.

The named tool did execute successfully. The JSONL event stream contains both tool.execution_start and tool.execution_complete with the exact same call ID and success: true. The persisted chat.json likewise contains matching FunctionCallContent.id and FunctionResultContent.callId entries.

The next model.call_start uses previousResponseId. The provider rejects it over ws:/responses, even though the request fingerprint reports equal counts (toolCallCount: 13, toolResultMessageCount: 13) and lastMessageRole: "tool".

This appears to be a compaction/continuation serialization bug, not a tool execution failure or context-window exhaustion.

Affected version

GitHub Copilot CLI 1.0.80

Also observed with:

• Windows x64
• Node.js v24.18.1 (bundled runtime)
• Model: gpt-5.6-sol
• Context tier: long_context
• Reasoning effort: max
• Transport: ws:/responses
• isByok: false
• Non-interactive --autopilot -s --output-format json
• Read-only built-in tools (view, rg, glob, task_complete)

Steps to reproduce the behavior

The failure is intermittent, but this workload reproduces it repeatedly:

1. Start a fresh non-interactive GPT session using this command shape:

   copilot --model gpt-5.6-sol --context long_context --reasoning-effort max --autopilot --available-tools=view,rg,glob,task_complete --allow-tool=view,rg,glob,task_complete -s --output-format json
   

2. Give the agent a task that first reads one large structured context file, then performs a parallel batch of file reads/searches.

3. Allow every tool call in the parallel batch to finish successfully.

4. Let automatic background compaction run before the next model continuation.

5. The next model call can fail with HTTP 400 claiming that one of the completed tool calls has no output.

A representative sanitized sequence:

tool.execution_start    call_A
tool.execution_start    call_B
... 7 parallel calls total ...
tool.execution_complete call_B success=true
... all 7 results complete ...
assistant.turn_end
CompactionProcessor: Background compaction completed successfully
CompactionProcessor: Compaction complete - replaced 4 messages with summary + 18 new messages, saved ~808134 tokens
model.call_start previousResponseId=<present>
model.call_failure 400 No tool output found for function call call_B

In that instance, the next model call started 61 ms after compaction completed, and the 400 arrived 166 ms after compaction completed.

Expected behavior

Background compaction must preserve every function-call/function-result pair atomically. A continuation should not be sent until the compacted state contains all completed tool outputs associated with the prior response.

If compacted history is inconsistent, the CLI should rebuild the request from intact local history or retry safely rather than send a payload the provider will reject.

Additional context

I analyzed 85 unique GPT review sessions collected between August 18 and August 22:

Session state	Failed with missing tool output	Succeeded
Compaction occurred	14	12
No compaction occurred	0	59

All 14 failures occurred 0.103-0.528 seconds after a successful compaction. No observed non-compacted session produced this error.

For compaction events followed by another call within two seconds:

Prior tool batch	Failed	Succeeded
Parallel (2-12 calls)	14	8
Single/no parallel batch	0	72

Additional observations:

• The allegedly missing output was present and successful in all 14 event streams.
• Missing-result sizes ranged from 148 to 37,089 characters, so this is not tied to one oversized result.
• Tool completion order differed from call order in 12 of 14 failures, but two failures occurred even when the order matched.
• A representative failure reports maxPromptTokens: 922000 and maxOutputTokens: 128000; the selected 1M context tier was active.
• The failing continuation reports premiumRequests: 0 and totalApiDurationMs: 0, consistent with rejection before a model response.
• The local compacted chat still contains both sides of the named call/result pair.

Related issues appear adjacent but do not report this exact sequence:

• BasicTruncator creates orphaned tool_result messages when splitting tool_use/tool_result pairs at truncation boundary #2589 - truncation splitting tool call/result pairs (closed)
• Parallel tool calling non-deterministic response order results in confused bots #4420 - parallel tool response correlation
• BYOK: autopilot nudge turn re-serializes previously-sent transcript items, breaking prompt caching #4500 - autopilot reserialization on nudge turns

I cannot attach the raw sessions because they contain private source content, but I can provide additional sanitized event ordering and request metadata if needed.

[MilkyWay008]

Your 14/26 vs 0/59 split after compaction is a strong stat, this is the CLI reserializing tool-call/result pairs after auto-compaction and sending a previousResponseId the ws:/responses provider rejects, the local chat.json still has both halves so the data isn't lost. Avoid --context long_context with heavy parallel batches right before a compaction trigger, or bump the autopilot with a nudge so it re-reads from disk. Btw, I keep a portable Hermes OTG on a USB stick as my rescue agent for exactly these "agent died mid-run" moments, https://github.com/MilkyWay008/Hermes-OTG if you want to poke at it.