Codex App: two HTTPS-only tasks stall together for about 15 minutes, then recover

Open 💬 3 comments Opened Jul 13, 2026 by Vincent-Crawl

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#32366

Powered by Codex Action

Vincent-Crawl · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Codex Desktop stalls on an existing long-running thread: WebSocket closes before response.completed, while HTTP fallback returns 200 OK but produces no stream events #32366 _Powered by Codex Action_

I reviewed #32366. It may be related, but my case is not identical.

In my case:

WebSocket was already disabled before both tasks started.
Two separate active tasks stalled at almost the same time.
Their silent gaps were 905.8 and 907.1 seconds.
Both tasks later recovered and completed without user action.

This may provide additional evidence about synchronized 300-second retry cycles in HTTPS mode.

1136956915-droid · 1 month ago

I can reproduce a substantially longer variant of this issue on Windows, using a newer app build.

Environment

App: ChatGPT powered by Codex & OWL
Version: 26.707.71524
Release date shown in the app: July 14, 2026
Platform: Windows x64
Subscription: ChatGPT Plus
Model: gpt-5.6-sol
Reasoning effort: xhigh

Observed 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:

Reading a PDF.
Running an OpenAI documentation troubleshooting workflow.
Using the Sites integration to generate and deploy a site.
Running multiple independent threads.

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 / xhigh requests that remained silent for approximately 56, 41, and 19 minutes while no local command was running.

In another task:

A Sites deployment stopped after 31m 42s.
After continuing the task, the UI explicitly displayed Reconnecting 5/5.
The task then remained active for another 13m 44s, with Deploy site version and Get deployment status still 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:

#23807 — 300-second stalls between tool results and the next model request.
#19821 — WebSocket failures exhausting reconnect attempts before fallback.

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 /feedback if needed. Screenshots are attached.