Windows Codex Desktop first prompt hangs ~8 minutes before retrying internal app-server / node_repl bootstrap

Open 💬 3 comments Opened Jun 9, 2026 by PeterSawatzki-MGGM
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

OpenAI.Codex_26.602.9276.0_x64__2p2nqsd0c76g0

Platform

Windows 11 Professional x64
Windows version from logs: Windows 10.0.26200
Codex Desktop on Windows

What issue are you seeing?

On a fresh Codex Desktop app start, the first user prompt regularly makes the UI/session appear dead for about 8 minutes. After that, Codex starts responding normally. This is reproducible.

The delay is not model latency. The actual model turn starts only after the long gap and then completes within a few seconds.

The logs show that the first internal node_repl.exe + codex.exe app-server --listen stdio:// pair starts immediately after the first prompt, then there is a long gap of about 490 seconds. After that, Codex starts a second internal node_repl.exe + codex.exe app-server --listen stdio:// pair and the request proceeds.

Steps to reproduce

  1. Completely close Codex Desktop.
  2. Verify no Codex.exe, codex.exe, or node_repl.exe processes are running.
  3. Start Codex Desktop.
  4. Send a first prompt: Test.
  5. Observe that the UI/session appears dead for about 8 minutes.
  6. After the hang, Codex answers normally.

Observed timings from multiple runs

  • 2026-06-09 14:47:13 to 14:54:57: gap ~464 seconds.
  • 2026-06-09 15:25:40 to 15:33:38: gap ~478 seconds.
  • 2026-06-09 16:55:31 to 17:03:22: gap ~471 seconds.
  • 2026-06-09 17:15:13 to 17:23:19: gap ~486 seconds.
  • 2026-06-09 17:40:52 to 17:49:03: gap ~491 seconds.
  • 2026-06-09 17:58:33 to 18:06:43: gap ~490 seconds.

Expected behavior

The first prompt should start the session and model turn without an 8-minute bootstrap delay.

Actual behavior

The session is delayed before the model turn. After about 8 minutes, a second internal app-server/node_repl pair starts and then the request continues.

Important log evidence

From %USERPROFILE%\.codex\logs_2.sqlite:

The recurring pattern is:

  1. thread/start with dynamic_tool_count=12.
  2. First node_repl.exe starts.
  3. First codex.exe app-server --listen stdio:// starts.
  4. Long gap around 470-491 seconds.
  5. Second node_repl.exe starts.
  6. Second codex.exe app-server --listen stdio:// starts.
  7. The user prompt is processed and model response completes quickly.

Example from the latest run:

  • thread/start logged: 17:58:31.762
  • first internal app-server process logs: 17:58:31.9xx
  • large log gap: 17:58:33.292 to 18:06:43.478, about 490 seconds
  • after the gap, request proceeds
  • session updated by 18:06:52

The model turn itself is not slow. It starts after the long gap and completes within seconds.

Tests already performed

  1. Waited about 30 minutes after starting Codex before sending the first prompt.

Result: hang still occurred. This shows the problematic bootstrap is triggered by the first prompt, not completed in the background during app startup.

  1. Temporarily disabled ngs-analysis by moving:

%USERPROFILE%\.codex\.tmp\plugins\plugins\ngs-analysis
Result: hang still occurred. ngs-analysis warnings are likely a side effect, not the root cause.

  1. Temporarily set browser plugin to disabled in:

%USERPROFILE%\.codex\config.toml
[plugins."browser@openai-bundled"] enabled = false
Result: hang still occurred.

  1. Temporarily disabled all normal plugin entries in config.toml:
  • documents@openai-primary-runtime
  • spreadsheets@openai-primary-runtime
  • presentations@openai-primary-runtime
  • sites@openai-bundled
  • browser@openai-bundled

Result: hang still occurred.

Important observation

Even with all normal plugins disabled in config.toml, logs still show:

app_server.client_name="codex-browser-use"

Also, dynamic_tool_count=12 remains unchanged even when all normal plugins are disabled.

This suggests the delay is caused by an internal Codex Desktop / app-server dynamic tool bootstrap path, not by user-visible plugin configuration.

Relevant process evidence

Typical failing run:

  • First pair:
  • node_repl.exe
  • codex.exe app-server --listen stdio://
  • After about 8 minutes:
  • second node_repl.exe
  • second codex.exe app-server --listen stdio://
  • Then the prompt is processed.

Diagnostic artifacts available locally

I have local diagnostic folders with process snapshots, extracted logs_2.sqlite windows, thread state, rollout JSONL timestamps, and live session checks during the hang. I can provide them if useful.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25697

Powered by Codex Action

PeterSawatzki-MGGM · 2 months ago

I added a sanitized diagnostic bundle as a secret Gist:

https://gist.github.com/PeterSawatzki-MGGM/70198f42b1b43e13693696e8b0260e09

Contents:

  • latest hang capture summary
  • selected logs_2.sqlite key lines around the hang
  • process snapshots before and after the hang
  • thread state
  • file-change window

Notes:

  • No raw SQLite database is included.
  • Full session JSONL files are not included.
  • Local username, workspace path, host name and installation ID were redacted.
  • The key evidence is the ~490s gap after the first prompt, with thread/start dynamic_tool_count=12, followed by a later retry/start where the response begins.
zbfg2001 · 2 months ago

i posted in another thread also - but man this is an issue that forces me to go to the dark side - claude doenst hang when i send in a new message, I like codex much better but the reason i have time to send this message is that I have been waiting for literally 5 minutes for another thread to start - this can't be right?