codex - 💡(How to fix) Fix Codex CLI intermittently gets stuck in “Working” state; reconnect retries occur before normal execution

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Codex should either continue making progress, show output, or fail with a clear recoverable error. If the backend/session/network is stalled, the CLI should detect that state and surface an actionable error or automatically recover instead of remaining indefinitely in Working (...) with no visible progress.

Root Cause

This is serious for automation workflows because it looks like Codex is still working, but in practice it may be stuck. I can come back much later and find that it never progressed.

Code Example

not available

---

Working (3m 06s • esc to interrupt)

---

Reconnecting... 1/5

---

OpenAI Codex v0.133.0
Model: gpt-5.5 (reasoning medium, summaries auto)
Directory: C:\project\daxing-erp
Permissions: Full Access
Collaboration mode: Default
Session: 019e34b2-5819-74c2-8af3-7114a69405f4

---

019e4059-180d-7ab3-ae18-4cc92fd31d0d
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

0.133.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5 (reasoning medium, summaries auto)

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What terminal emulator and version are you using (if applicable)?

PowerShell on Windows; also using psmux in some sessions

Codex doctor report

not available

What issue are you seeing?

I am seeing two intermittent Codex CLI reliability issues.

  1. Severe issue: after sending a message, Codex sometimes remains in a status like:
Working (3m 06s • esc to interrupt)

The timer keeps increasing, but there is no visible progress or output. This can last more than ten minutes. If I press Esc to interrupt and then send the exact same message again, it may immediately run normally.

This also sometimes happens in the middle of a task: Codex has already started doing work, then it reaches a Working (...) state and stops making visible progress indefinitely.

This is serious for automation workflows because it looks like Codex is still working, but in practice it may be stuck. I can come back much later and find that it never progressed.

  1. Less severe issue: when sending a message, Codex sometimes shows reconnect messages such as:
Reconnecting... 1/5

It may retry up to 5 times, and after those failures it can still start running normally. This adds one or two minutes of delay, but is less damaging than the indefinite Working (...) hang.

I do not know whether these two symptoms have the same root cause, but they both look like intermittent CLI/session/network state issues.

What steps can reproduce the bug?

The issue is intermittent, so I do not have a deterministic minimal repro yet.

Observed workflow:

  1. Start Codex CLI.
  2. Send a normal task message.
  3. Sometimes Codex enters Working (Xm Ys • esc to interrupt) and stays there without visible progress for many minutes.
  4. Press Esc to interrupt.
  5. Send the exact same message again.
  6. The same request may then execute normally.

It can also happen after Codex has already started a multi-step task: the run reaches a Working (...) status and then appears stuck.

Session / environment details from one affected session:

OpenAI Codex v0.133.0
Model: gpt-5.5 (reasoning medium, summaries auto)
Directory: C:\project\daxing-erp
Permissions: Full Access
Collaboration mode: Default
Session: 019e34b2-5819-74c2-8af3-7114a69405f4

The issue form URL also included an uploaded thread id:

019e4059-180d-7ab3-ae18-4cc92fd31d0d

What is the expected behavior?

Codex should either continue making progress, show output, or fail with a clear recoverable error.

If the backend/session/network is stalled, the CLI should detect that state and surface an actionable error or automatically recover instead of remaining indefinitely in Working (...) with no visible progress.

For reconnect attempts, the CLI should make clear what it is reconnecting to and whether the retry sequence affects the submitted prompt.

Additional information

Impact: high for the Working (...) hang because it can break unattended automation. The reconnect issue is lower impact because it usually resolves after a short delay.

I am filing both symptoms together because they both occur around message submission / run execution and may be related to session or transport state.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING