Loading spinner not showing when starting codex with initial prompt

Resolved 💬 3 comments Opened Nov 20, 2025 by 2mawi2 Closed Jan 13, 2026

💡 Likely answer: A maintainer (lionel-oai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

v0.61.0

What subscription do you have?

Proi

Which model were you using?

gpt-5.1-codex-max

What platform is your computer?

Darwin 25.1.0 arm64 arm

What issue are you seeing?

Since recent releases the loading animation is broken when starting codex with a direct inline start prompt:

e.g. '• Working (1s • esc to interrupt)' is not shown anymore when starting codex like this: codex 'build an xmas tree'

What steps can reproduce the bug?

To reproduce in Ghostty

codex 'build an xmas tree'

no loading spinner shows:

When starting codex directly and prompting manually:
codex -> then type the prompt manually

loading spinner shows perfectly

What is the expected behavior?

The loading animation should also show with an initial prompt: '• Working (1s • esc to interrupt)'

Additional information

_No response_

View original on GitHub ↗

3 Comments

lionel-oai contributor · 9 months ago

Hi @2mawi2 thanks a lot for raising a bug. I just tried exactly with your setup (gpt-5.1-codex-max with xhigh reasoning) and it seems that on my Mac terminal (I use Ghostty as well with powerlevel10k) I am able to see the spinner:

https://github.com/user-attachments/assets/b985efd5-608c-41d7-a43c-c40d1f252388

The only difference between our setup might the terminal setup: are you using oh-my-zsh with some custom theme?

2mawi2 contributor · 9 months ago

Hi @lionel-oai,

I can consistently reproduce the missing “Working…” spinner only when starting Codex with an inline prompt on multiple Macs in multiple shell types.

I let codex debug my environment and started 2 runs (one with and one without inline prompt) with 'RUST_LOG=codex_core=trace,codex_tui=trace'

Details:

Environment: macOS (arm64), codex-cli 0.61.0 via Homebrew (/opt/homebrew/

bin/codex), shell zsh, workdir ~. Also repro’d on a second Mac, in bash/
zsh/fish, and in Ghostty and the default macOS Terminal. Also tried to change font type, didn't help.

Config in the trace: approval_policy: UnlessTrusted; sandbox

WorkspaceWrite with network access disabled; no custom inline aliases/
wrappers.

Inline run (codex 'build an xmas tree', session 019aa5d5…):
Log: SessionConfigured … initial_messages: None … cwd: ~ → UserInput

"build an xmas tree" → TaskStarted → user message events. No errors/
warnings. Spinner does not appear.

Manual run (codex, then type “build an xmas tree”, session 019aa5d6…):
Log: same shape (initial_messages: None, UserInput "build an xmas

tree", TaskStarted), but the spinner does appear in the TUI.

Only unrelated warning: Operation not permitted when shellenv.sh tried /

bin/ps during inline run; otherwise clean.

So both paths emit TaskStarted without errors, but the inline start
never shows the status line even though the task starts. Also notable:
initial_messages is None even for the inline start, so the TUI never treats
it as an auto-submitted initial prompt.

Can I provide you anything else?

2mawi2 contributor · 7 months ago

@lionel-oai I found the problem.

I had configured a global MCP server. When starting with a start argument McpStartupComplete was unconditionally calling bottom_pane.set_task_running(false). I build a quick PR and in my manual testing this resolved the issue.

#8661