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

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?

1. Sign in to Codex App with a ChatGPT subscription.
2. Use an HTTPS-only provider with supports_websockets = false.
3. Open two separate tasks.
4. Select gpt-5.6-sol with High reasoning.
5. Start long tasks that use several tools.
6. Leave both tasks running.
7. 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.