Repository navigation
Codex App: two HTTPS-only tasks stall together for about 15 minutes, then recover #32764
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.62119 (build 5211)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
Two tasks were running at the same time in Codex App. Both tasks suddenly stopped showing new reasoning or tool events.
The App stayed responsive and still showed the Stop button. No error or reconnect message appeared.
Both tasks later resumed by themselves and completed successfully. The silent gaps were 905.8 seconds and 907.1 seconds.
My Codex uses HTTPS/SSE, not WebSocket:
model_provider = "openai_http"
supports_websockets = false
This has happened more than once.
What steps can reproduce the bug?
- Sign in to Codex App with a ChatGPT subscription.
- Use an HTTPS-only provider with supports_websockets = false.
- Open two separate tasks.
- Select gpt-5.6-sol with High reasoning.
- Start long tasks that use several tools.
- Leave both tasks running.
- Sometimes both tasks stop showing progress for about 15 minutes, then resume without any user action.
What is the expected behavior?
Each task should continue independently.
If a response stream stalls, Codex should detect it quickly, retry, and show a clear status. It should not appear frozen for several 300-second periods.
Additional information
Observed on July 13, 2026 (UTC):
- Task A: last event at 09:31:11, resumed at 09:46:17 — 905.8 seconds.
- Task B: last event at 09:31:35, resumed at 09:46:43 — 907.1 seconds.
The two tasks stopped and resumed about 25 seconds apart.
Local tool commands had already finished. The Mac did not sleep, the App did not crash, and no rate limit was reached.
Approximate context usage before the stall:
- Task A: 53,120 / 258,400 tokens.
- Task B: 75,531 / 258,400 tokens.
A separate HTTPS request remained silent for more than 300 seconds through the same proxy and still completed successfully. This suggests there is no fixed 300-second proxy timeout.
This may be related to #23807.
I can provide the affected thread IDs privately through /feedback if needed.
Activity
github-actions commentedon Jul 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Vincent-Crawl commentedon Jul 13, 2026
I reviewed #32366. It may be related, but my case is not identical.
In my case:
This may provide additional evidence about synchronized 300-second retry cycles in HTTPS mode.
1136956915-droid commentedon Jul 14, 2026
I can reproduce a substantially longer variant of this issue on Windows, using a newer app build.
Environment
26.707.71524gpt-5.6-solxhighObserved behavior
Since July 13/14, multiple unrelated tasks have repeatedly stopped producing new reasoning, tool, or progress events for very long periods. The app remains responsive and continues showing the Stop button, but the task stays on its last visible status.
This is not limited to one PDF or one project. I have reproduced it while:
Observed stalls include approximately 56, 41, 37, 31, 19, and 14 minutes.
One diagnostic thread remained active for at least 37m 30s with no new progress. Its local diagnostic output reported three earlier
gpt-5.6-sol / xhighrequests that remained silent for approximately 56, 41, and 19 minutes while no local command was running.In another task:
Reconnecting 5/5.Deploy site versionandGet deployment statusstill visible.Sometimes there is no reconnect message at all; the UI simply remains on “Thinking”, “Running command”, or another last-known activity label. In at least one interrupted task, the assistant also reported that it had not retained the concrete task state.
There was no visible approval request. The issue appeared suddenly and affects multiple independent threads.
Expected behavior
If the model response stream or tool-result handoff stalls, Codex should detect it quickly, retry, or return a clear error. It should not remain silently active for tens of minutes while displaying a stale activity label.
This may be related to:
This reproduction is on app version
26.707.71524, which is newer than the version originally reported in this issue, so the problem still appears to be present in the latest Windows build.I can provide affected thread IDs privately through
/feedbackif needed. Screenshots are attached.