Desktop document-preview images accumulate again after recovery; individual threads repeatedly reconnect and remote compaction can fail

Environment

• ChatGPT/Codex desktop app: 26.1002.52244 (build 13536), bundle identifier com.openai.codex.
• Bundled CLI: codex-cli 0.162.0-alpha.2.
• macOS 15.5, Apple Silicon arm64.
• Affected model in local logs: gpt-6-astra, reasoning effort high.
• Subscription tier: not collected.
• Network: local proxy/VPN in use. Other conversations can work while an affected conversation fails. No controlled network A/B test was performed; a network contribution remains possible.
• Observed on 2026-10-08 and 2026-10-09. Times below are Asia/Shanghai (UTC+08:00).

User-visible problem and impact

An ordinary Word/PPT editing workflow becomes difficult to continue after the agent reads rendered document pages as images. The original upload may be just one Word document, but image-producing tool outputs add multiple inline images to the conversation. Affected old threads repeatedly show Reconnecting, while the user reports the same instruction works in a new conversation.

The user also observed this error during /compact:

Error running remote compact task: stream disconnected before completion: error sending request

Repeated manual history repair or abandoning the conversation is disruptive. Reading ten document pages for visual quality assurance should not make a working thread unusable without an actionable explanation or supported recovery path.

Local evidence: case A, recurrence after verified recovery

The evidence distinguishes persisted history, estimated active inline-image bytes, and actual logged HTTP request bytes. Image byte counts below measure encoded data-URL strings, not decoded image size, RAM use, model tokens, or an established service limit.

1. Before a local repair at approximately 15:14 on October 9, this thread contained 32 remaining inline image occurrences, totaling 40,136,536 encoded bytes. The latest replacement history plus later response items also contained these 32 images.
2. A prior HTTP fallback log at 15:06:31 recorded pre_compression_bytes=40677010, post_compression_bytes=23168777. Earlier attempts showed Broken pipe and repeated retries. These request-size measurements are from BEFORE the 15:14 repair, not the later 11-image recurrence.
3. After the repair, a minimal no-tools test completed in 10,896 ms with the requested acknowledgement. The recorded validation found no warnings during that test.
4. The user resumed document editing. New image content entered history:

5. At 15:19:13, after the first batch, a log already reported websocket closed by server before response.completed. Further failures followed after the next batch. At 15:57:51 and 15:59:18 the logs reported Broken pipe; at 15:57:52 they reported tls handshake eof.
6. A later read-only audit found exactly those 11 inline image occurrences, all in records appended after the repair. The SHA-256 of the repaired prefix still matched the recorded post-repair SHA-256. Thus the previous cleanup did not revert: the new images were subsequent additions.

Local evidence: case B, another affected old conversation

Before repair, a separate thread had 22 compaction records. Its entire persisted history contained 1,381 image occurrences (800,554,115 encoded bytes), while the estimated active history contained 48 image occurrences (46,913,017 encoded bytes). These are distinct measurements; the full persisted history is not the request body.

After externalizing its image payloads, a minimal no-tools test completed in 20,362 ms with the requested acknowledgement. No WARN/ERROR entries for that thread were found during the test interval. A subsequent read-only audit found zero remaining inline images.

Workaround used and limitations

These are observations from an UNSUPPORTED LOCAL RECOVERY experiment, not an official fix or a recommendation that users edit rollout files:

• Unload/archive only the affected idle conversation and back up its complete rollout.
• Save each typed inline input_image payload losslessly to a persistent local file, deduplicated by content hash, and replace it with an input_text path reference.
• Preserve all other fields, record order, tool-call relationships, summaries, and encrypted fields.
• Preserve each JSONL record's original byte length and offset using trailing JSON whitespace. Physical file size therefore does not demonstrate retained model-visible image content.
• Restore the conversation and send one minimal no-tools acknowledgement test.

This changes model-visible visual history and tests only minimal connectivity; it does not establish normal-task recovery or a sole root cause. The successful tests and recurrence are suggestive of a retained-image/request-size contribution. There is no controlled server-side experiment, no verified universal 15 MB limit, and no explicit HTTP 413 or WebSocket 1009 evidence in the excerpts collected for this report. TLS/proxy/backend problems are not excluded. The problem existed before local recovery edits; those edits are disclosed because they are relevant to interpretation.

Observed workflow to investigate

1. In a persistent desktop conversation, edit a multi-page Word or PowerPoint document.
2. Render pages and inspect them through image-returning tools (for example, view_image), including several pages in one tool output.
3. Continue the same conversation as image outputs accumulate.
4. Observe repeated reconnects; compare a new conversation on the same machine/network and try manual compaction in the affected history.
5. Inspect the latest compacted replacement_history plus later response items separately from all persisted historical records.

These steps describe the observed private-document workflow, not a independently validated synthetic reproducer. Private documents and pixels are not attached.

Requested engineering investigation

• Correlate transport failures with retained encoded image bytes independently of token/context budgeting.
• Bound the active multimodal payload while preserving recent, relevant visual context and document-checking quality.
• Avoid requiring an already failing oversized history to be sent unchanged for recovery/compaction.
• Provide a supported per-thread inspection and recovery action with backups and integrity checks.
• Show actionable errors when image payload, proxy/TLS, or backend limits are implicated, rather than repeated generic reconnects.
• Consider coverage for image-producing tool outputs during multi-page document workflows, not only user-uploaded screenshots.

Related reports

• Local compaction v2 retains unbounded input_image payloads, causing repeated auto-compaction #33493: inline image retention and repeated compaction.
• Bedrock Runtime: inline image history still overflows after successful compaction #46247: encoded image history constraints on Bedrock, a different provider; not evidence of an identical limit here.
• Stream disconnected error. Possibly related to auto-compaction. #48685: stream disconnection around compaction and image-producing computer-use work.

This report adds an observed clean-prefix verification followed by tool-generated image reaccumulation on desktop 26.1002.52244 / bundled CLI 0.162.0-alpha.2. Please consolidate with an existing issue if appropriate.

Privacy

Only reviewed structural measurements and error excerpts are included. No source documents, image pixels, raw rollouts, private prompts, local paths, credentials, account identifiers, or thread/turn IDs are included publicly. A local sanitized evidence JSON and this report have been packaged for the user.