[macOS] Repeated ~300-second stalls in Codex Desktop across different models

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.20858

What subscription do you have?

Team

What platform is your computer?

Darwin 24.1.0 arm64 arm

What issue are you seeing?

I am seeing repeated stalls of approximately 300 seconds (5 minutes) while running tasks in Codex Desktop on macOS.

This does not appear to be explained by local command execution or simply by long model reasoning. Based on the rollout JSONL, there are repeated intervals where processing appears to stop for roughly five minutes and then resume.

Reproduction across separate sessions

I have observed this in at least two separate Codex Desktop sessions using different model configurations.

September 3, 2026

Model: GPT-5.6 Sol
Reasoning effort: Medium

During one task, I observed gaps of approximately:

• 303.649 seconds
• 305.103 seconds
• 309.844 seconds

Additional similar gaps of approximately 302–309 seconds occurred later in the same session.

For several of these intervals, aggregate token usage was completely unchanged before and after the gap, and no rollout event was recorded between the two token_count events.

The local commands immediately preceding some of these intervals completed in approximately 0.1 seconds or less, so the delay was not caused by local command execution.

September 5, 2026

Model: GPT-6 Astra
Reasoning effort: High

I again observed the same pattern, including:

• 300.513 seconds
• approximately 304 seconds with no further event after a reasoning item
• approximately 310.854 seconds with no recorded event before processing resumed

In the clearest example, a web search completed in approximately 1.9 seconds. A token_count event was recorded immediately afterward, followed by approximately 300.5 seconds with no rollout event. The next token_count had exactly the same token usage values.

Rate limiting also does not appear to explain the behavior. During the relevant intervals, rate_limit_reached_type was null.

Temporal pattern

There may also be a useful correlation with service health:

• September 3: the repeated ~300-second stalls occurred.
• Later that night, a broader GPT/OpenAI service outage occurred.
• September 4: I did not observe this ~300-second stall behavior.
• September 5: the same ~300-second behavior appeared again.

I am not claiming that the September 3 stalls caused or predicted the later outage. However, because the behavior disappeared on September 4 and then reappeared on September 5, it may be worth correlating these timestamps with backend/service-health telemetry.

The fact that the same behavior occurred with different model configurations also makes a model-specific issue seem less likely.

Why I suspect a timer-based backend or streaming issue

The repeated delays cluster unusually closely around 300 seconds.

For the strongest examples:

• token usage does not change during the interval
• no rollout event is recorded during the interval
• local tools finish much faster than the observed delay
• rate limiting is not active
• processing suddenly resumes afterward

This makes me suspect a request/stream timeout, watchdog, backend wait, connection recovery, or internal retry path with a timeout around 300 seconds.

However, the rollout JSONL does not contain an explicit timeout, retry, or connection failure event, so I cannot determine the exact cause from the client-side logs alone.

Request

Could you please correlate the attached timestamps with server-side/backend telemetry and check whether any of the following occurred?

• request timeout
• streaming timeout
• watchdog expiration
• connection/reconnection delay
• internal retry
• backend routing or capacity issue
• context-processing or compaction wait

It would also be very helpful if future rollout JSONL files explicitly recorded timeout/retry/reconnect events when they occur, because currently these ~300-second gaps are visible but their cause is not.

I have attached a sanitized diagnostic extract containing only timestamps, model/client metadata, token counts, rate-limit status, and tool durations. It excludes conversation contents, local paths, workspace names, commands, search queries/results, internal IDs, and encrypted reasoning payloads.

codex_300s_stall_anonymized_report.txt

What steps can reproduce the bug?

The issue is intermittent and I do not have a deterministic reproduction sequence.
I observed it on September 3 with GPT-5.6 Sol / Medium and again on September 5 with GPT-6 Astra / High. On September 4, I did not observe the issue.
When it occurs, a normal Codex task enters repeated stalls clustered around 300–310 seconds. The attached sanitized diagnostic extract contains the exact UTC timestamps and token-count evidence.

What is the expected behavior?

No response

Additional information

No response

Start with the attached sanitized diagnostic extract and its UTC timestamps, then correlate the reported rollout JSONL gaps with server-side and service-health telemetry. Check the listed timeout, reconnect, retry, routing, and context-processing possibilities; done means identifying the cause or documenting which telemetry is missing, including whether explicit timeout or retry events should be recorded.