dire vectorReported by @devout stag
#Codex Desktop remote context compaction repeatedly fails with stream disconnected before completion
devout stag
Bug Title
Codex Desktop remote context compaction repeatedly fails near the automatic compaction threshold with:
stream disconnected before completion
Steps to Reproduce
Open Codex Desktop.
Start or continue a long-running conversation with substantial context.
Continue the thread until Codex reaches the point where it automatically attempts context compaction.
Let Codex perform the automatic compact operation.
Observe that Codex repeatedly attempts to compact, but the remote compact request fails.
The visible user-facing error is:
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
Automatically compacting context
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
Automatically compacting context
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
This happens when the conversation has grown large enough that Codex needs to compact context before continuing.
Expected Result
Codex should successfully complete the remote context compaction request.
After compaction succeeds, the conversation should continue normally with the relevant thread state preserved. The user should not need to manually restart the task, open a new thread, or lose working context.
If the compact request fails transiently, Codex should either retry successfully or provide a recoverable fallback path.
Actual Result
Codex repeatedly fails to complete the remote compact task.
The local logs show the failing request is made to:
POST https://chatgpt.com/backend-api/codex/responses/compact
The observed failure is:
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
The observed failure is:
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
From local logs, this does not look like a basic connectivity issue or an obvious auth failure:
endpoint="/responses/compact"
auth_header_attached=true
auth_header_name="authorization"
auth_mode="Chatgpt"
auth_retry_after_unauthorized="false"
auth_error=""
auth_error_code=""
The failed request attempts appear to run for about 15 seconds before failing:
duration_ms=15311
duration_ms=15319
duration_ms=15302
The compact request was large, but within the kind of situation where automatic compaction is expected to work:
last_api_response_total_tokens=231559
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=962430
Relevant error log excerpt:
remote compaction failed
turn_id=...
last_api_response_total_tokens=231559
all_history_items_model_visible_bytes=941083
estimated_tokens_of_items_added_since_last_successful_api_response=0
estimated_bytes_of_items_added_since_last_successful_api_response=0
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=962430
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
The request appears to connect successfully before later failing:
starting new connection: https://chatgpt.com/
connecting to 172.64.155.209:443
connected to 172.64.155.209:443
http1 handshake complete
connection is ready
checkout dropped for ("https", chatgpt.com)
A manual connectivity check to the same endpoint also reached the server immediately:
curl -I https://chatgpt.com/backend-api/codex/responses/compact
returned
HTTP/2 405
allow: POST
server: cloudflare
x-oai-request-id: ...
That suggests DNS/TLS/basic route availability is working. The failure appears specific to the authenticated large remote compact POST/stream, not to reaching chatgpt.com generally.
Environment
Product: Codex Desktop
Codex app version: 26.429.61741
Bundle identifier: com.openai.codex
Bundle version: 2429
Internal logged app version: 0.128.0-alpha.1
OS: macOS 26.2
macOS build: 25C56
Model: gpt-5.5
Auth mode: ChatGPT auth
Failing endpoint:
POST https://chatgpt.com/backend-api/codex/responses/compact
Normal response transport observed in logs
transport="responses_websocket"
api.path="responses"
Suggested config flags were not explicitly present in local ~/.codex/config.toml:
[features]
responses_websockets = true
responses_websockets_v2 = true
Existing config had:
[features]
rmcp_client = true
memories = true
A suggested workaround was:
[features]
responses_websockets = true
responses_websockets_v2 = true
However, local logs already show normal model turns using responses_websocket, while the failing compact path uses the separate responses/compact endpoint. Because of that, it is unclear whether changing websocket flags would affect this issue.
This may be a reliability issue in the remote compact endpoint, a timeout on large authenticated compact requests, or a client-side timeout/stream handling problem around the compact POST request.
@dire vector
lethal knot
Check this cookbook, maybe can provide you more ideas in the meantime: https://developers.openai.com/cookbook/examples/agents_sdk/building_reliable_agents_memory_compaction
devout stag
Check this cookbook, maybe can provide you more ideas in the meantime: https://...
this is cool but its directly a problem with codex compaction.
lethal knot
this is cool but its directly a problem with codex compaction.
Im getting frustrated with this compaction and the queued messages overriding the plan mode plans approvals.
devout stag
update: correlation does not imply causation but I restarted my router and computer + next day and the issue resolved itself.
lethal knot
update: correlation does not imply causation but I restarted my router and compu...
the compaction?