[macOS Desktop] Automatic compaction stalls with WebSocket idle timeout; persists after app restart

What version of the Codex App are you using?

Installed desktop bundle inspected after the incident: 26.901.41123 (build 7942), bundle identifier com.openai.codex. The installed application is named ChatGPT and the affected surface is its Codex task UI. This is installed-bundle evidence, not a separate confirmation of the build loaded at the start of the affected turn.

What subscription do you have?

Not included in this report.

What platform is your computer?

macOS / Darwin 25.6.0, arm64.

What issue are you seeing?

A long-running Codex task remains in automatic context compaction and reconnect attempts without delivering further task output. I waited more than twenty minutes and restarted the desktop app, but the problem persisted. The waiting duration and unsuccessful restart are my observations, not a controlled timing measurement.

The visible activity sequence was:

Ran command
Success
Context automatically compacting
Reconnecting 2/2
stream disconnected before completion: idle timeout waiting for websocket

The preceding shell command was shown as successful. The connection error appeared afterward, while the UI showed automatic context compaction. This does not establish that the shell command or any particular script caused the failure.

A read-only native task status check during the incident still returned active / inProgress with a null terminal error and no new message or tool marker in the latest attempt. This conflicts with using the running indicator as evidence of productive progress; it does not establish that execution has recovered.

I also opened Voice in the affected task and it appeared to be waiting. I have not established whether Voice is relevant to the underlying failure.

What steps can reproduce the bug?

Observed sequence, not a deterministic minimal reproduction:

1. Run a long Codex task until automatic context compaction starts.
2. Observe prolonged compaction followed by reconnect attempts and the WebSocket idle-timeout error above.
3. Wait for recovery; no further task result was confirmed during the observation.
4. Restart the desktop app and reopen the same task; the problem remains visible.

The screenshot documenting the error was taken September 4, 2026 at approximately 20:33 EDT (September 5 at 00:33 UTC). It is intentionally not attached because it contains private task content.

The task composer displayed GPT-6 Astra / Max. That is a UI observation, not independent runtime attribution or evidence that the model caused the failure.

Troubleshooting attempted after the initial report

After restarting the desktop app did not resolve the visible stall, I tried the following in the affected task:

1. Used Clear on the Goal.
2. Used Stop on the running task.
3. Requested manual context compaction to see whether it could complete.

I still do not see progress after these steps. This is my current observation; successful manual compaction or recovery has not been confirmed.

Read-only native inspection confirmed that the preceding attempt became interrupted. A subsequent attempt appears as inProgress, with a null terminal error and no latest assistant message or tool marker exposed in the status snapshot. The most recent check was at 2026-09-04 20:50:23 EDT (UTC-0400) / 2026-09-05 00:50:23 UTC. These fields do not independently confirm that Goal clearance succeeded, that the later attempt is the manual compaction operation, or that useful execution has resumed.

The inspection did not restart or resume the stopped drafting task. The unresolved issue is whether compaction can finish and provide an accurate, actionable recovery state after these manual controls.

What is the expected behavior?

Automatic compaction should complete and continue the existing task, or report a clear recoverable failure. If a stream times out, the UI should distinguish actual execution from reconnecting or failed recovery and expose a supported way to continue the same task without losing its completed work or duplicating actions.

Uploaded performance trace

The app displayed Performance trace uploaded and supplied this Feedback ID:

01a06eb8-7aa2-7981-a85f-9f95ea5da9f4

Please correlate the uploaded trace with the compaction and reconnection interval. The upload confirmation does not establish that engineering has reviewed the trace.

Related reports and diagnostic limits

• #27625 reports the same WebSocket idle-timeout wording and repeated desktop reconnects on an older version.
• #36059 reports broader desktop stream reliability failures.
• #42693, opened September 4, concerns failure to continue after compaction; its reported behavior differs from remaining stuck during compaction.

This report adds the current compaction-stage stall, persistence after my app restart, native status discrepancy, and uploaded trace. A shared root cause with those reports is not established.

OpenAI Status displayed fully operational when checked around 20:34 EDT. No general outage, network cause, or model-specific regression is asserted.

No private documents, task prompts, local paths, credentials, raw logs, or screenshots are attached.

Start by reviewing the compaction and reconnect behavior described here, then correlate the uploaded performance trace using Feedback ID 01a06eb8-7aa2-7981-a85f-9f95ea5da9f4. Compare the behavior with reports #27625, #36059, and #42693 while reproducing the long-task sequence if possible. Done means compaction either continues the task or exposes a clear recoverable failure without duplicating actions.