CLI stays on “Working” without visible tool activity or a response to an interrupted status request

What version of Codex CLI is running?

codex-cli 0.154.0

What subscription do you have?

PRO 5X

Which model were you using?

gpt-6-astra, medium reasoning effort

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Windows terminal

Codex doctor report

Ran codex doctor --json
  └ {
      "schemaVersion": 1,
    … +358 lines (ctrl + t to view transcript)
      }
    }

───────────────────────────────────────────────────────────────────────────────────────────────────

• codex doctor --json completed successfully (exit code 0).

  - Overall status: ok
  - Codex version: 0.154.0
  - Authentication configured; HTTP and WebSocket checks passed.
  - Configuration and state databases healthy.
  - Free disk space: 10.2 GiB.

What issue are you seeing?

Codex acknowledged a backup troubleshooting task, then displayed “Working” for several minutes without visible commands, tool results, access requests, errors, or progress updates.

I requested a status update while the task was running. The CLI queued my message with:

“Messages to be submitted after next tool call (press esc to interrupt and send immediately)”

I pressed Esc. The CLI confirmed:

“Model interrupted to submit steer instructions.”

My status request appeared as the next user message, but Codex returned to “Working” for another 1 minute 30 seconds without answering.

Observed sequence:

Initial response:
“I’ll verify access, inspect the existing backup workflow and failure logs, then repair and test the failing stages without changing schedules or retention.”

Status:
“Working (4m 44s • esc to interrupt)”

Follow-up prompt:
“Give me a progress update now. Which host have you reached, what command is running, what has completed, and are you waiting for access or a command result? Continue the backup repair and provide brief updates at least once a minute. Keep credentials out of the output.”

After pressing Esc:
“Model interrupted to submit steer instructions.”

Subsequent status:
“Working (1m 30s • esc to interrupt)”

The interface accepted the interruption, but provided no substantive response afterward. I have no evidence whether a remote command started, whether a model request was pending, or whether execution stalled.

What steps can reproduce the bug?

Uploaded thread: 01a0924f-b8a6-7193-8ce8-dc816b135eae

What is the expected behavior?

Codex should respond to an explicit status request with the last completed action, any active command, and any known blocker.

During extended waits, the CLI should expose the available execution state, such as waiting for a model response, executing a tool, awaiting approval, or retrying a connection. If the underlying state is unknown, say so.

After accepting an interruption and submitting the follow-up message, Codex should answer or report an actionable error rather than return indefinitely to an unexplained “Working” indicator.

Additional information

The original task involved existing device backups and NAS replication. No credentials are included in this report.

No error or approval prompt appeared in the captured output. I interrupted the original wait, so I cannot establish whether the request would eventually have completed.

The lack of execution visibility prevented me from distinguishing a slow response from a stalled task. I decided to investigate the backups manually in a separate terminal.

Start by reproducing the uploaded thread 01a0924f-b8a6-7193-8ce8-dc816b135eae on Windows Terminal, then trace the CLI's “Working” indicator, interruption handling, and queued status-message path. Done means an interrupted status request receives a response or actionable error, and extended waits expose whether the CLI is waiting on a model, tool, approval, or retry.