apply_patch stores deleted binary in session history, permanently exceeding CAPI 5 MB limit

[Adamkadaban]

Describe the bug

When apply_patch deletes a large binary file, its tool.execution_complete event stores the entire deleted binary as a textual diff in result.detailedContent.

This result remains in conversation history. Subsequent requests exceed CAPI Responses' 5 MB limit, and /compact fails for the same reason, leaving the session unrecoverable through the CLI.

Affected configuration

• GitHub Copilot CLI 1.0.71-0
• Linux
• Model: GPT-5.6 Sol (gpt-5.6-sol)
• Context window: 1.1M
• Reasoning effort: high
• Interactive session later resumed with copilot --resume=<session-id>

The model, context-window size, and reasoning effort may affect when compaction runs, but the persisted binary tool output appears to be the direct cause of the 5 MB transport failure.

Observed sequence

1. Copilot used apply_patch to delete a large ELF executable.

2. The persisted event contained:

   • result.detailedContent: 22,810,594 characters
   • Serialized JSONL record: 72,155,553 bytes
   • Tool telemetry: 111,879 removed lines

3. events.jsonl grew to 118,622,622 bytes.

4. Further requests failed with:

   The request is too large to send through CAPI Responses. Try shortening the conversation or prompt. (5.0 MB request; 5.0 MB limit)

5. Automatic/manual compaction failed with the same error.

Expected behavior

Binary content should not be persisted as a textual patch. The CLI should retain deletion metadata while omitting or capping oversized detailedContent.

After a request-size failure, oversized tool output should be evicted so compaction can recover the session.

Workaround and root-cause confirmation

After backing up the session, I replaced the oversized detailedContent with a short marker. This reduced the event log from 118.6 MB to 46.5 MB and eliminated the CAPI request-size failure.

Related issues

This resembles #3767, but that issue covered inline attachments and was fixed in v1.0.62. This report concerns persisted apply_patch output in v1.0.71.

The session also developed malformed JSONL records that prevented resume, reported separately in #4098. The shared root cause is not proven, although the unusually large write may have widened the failure window.

I have not attached events.jsonl because it contains conversation and tool history.

---

Investigated and filed with assistance from GitHub Copilot CLI.

[divega]

Hitting the same symptoms quite consistently with gpt-5.6-sol on Windows, although I haven't tried to find the underlying cause, so I don't know if it is also apply_patch. My context was at 62% of 1.1 million tokens when I started getting the error.