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

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 ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗