Windows: codex-plugin-cc hangs at “Initializing…” when launching `codex app-server`; likely broker/spawn/ stdio issue

[LiXY-SmartCity]

Environment:

• OS: Windows 11 Pro
• codex-cli: 0.121.0
• codex-plugin-cc: 1.0.3 (codex@openai-codex)
• Auth mode: ChatGPT Plus login
• Claude Code CLI with codex-plugin-cc

Problem:
When triggering /codex:rescue --fresh <prompt> inside Claude Code, the Codex child agent stays at
“Initializing…” indefinitely with no output and no visible error.

What I expected:
The plugin should successfully start codex app-server, complete the JSON-RPC handshake, and begin processing
the request.

What actually happens:

• The child agent shows “Initializing…” for several minutes
• No output is produced
• No explicit error is surfaced to the user
• Reproduces both via slash command and Skill-triggered path

Important clarification:
This is not using codex exec. I checked the plugin source and it actually uses codex app-server.

Observed plugin architecture:

1. Default path:

   • spawn a detached Node broker process (app-server-broker.mjs)
   • broker launches codex app-server
   • client connects to broker over socket

2. Fallback path:

   • directly spawn codex app-server
   • stdio: ["pipe", "pipe", "pipe"]
   • write JSON-RPC messages to stdin
   • read stdout line-by-line

Why I believe this is a plugin-side Windows spawn/broker issue:

1. codex app-server itself works on this machine
   I successfully ran:

   • codex login status
     -> Logged in using ChatGPT
   • codex debug app-server send-message-v2 "Reply with exactly OK."

   This successfully completed:

   • initialize
   • initialized
   • thread/start
   • turn/start
   • final response OK

   It also showed:

   • platformFamily: "windows"
   • platformOs: "windows"
   • planType: "plus"

   So:

   • codex app-server is functional on Windows in this environment
   • ChatGPT Plus auth / ~/.codex/auth.json is being read correctly
   • stdio JSON-RPC handshake itself is not fundamentally broken here

2. Broker state files are never created
   In %CLAUDE_PLUGIN_DATA%/state/<workspace>/, there is no:

   • broker.json
   • broker.pid
   • broker.log

   This suggests the broker session either:

   • never started correctly
   • failed before persisting state
   • or was torn down immediately

3. ~/.codex/log/codex-tui.log timestamps do not match my /codex:rescue attempts
   That suggests my Claude Code attempts may never be reaching a real Codex app-server session.

Suspicious implementation detail:
On Windows, the direct spawn path uses:

• shell: process.env.SHELL || true

This looks high-risk for a protocol process like codex app-server, because app-server expects clean JSONL
over stdio.
Wrapping it in cmd.exe / bash / pwsh can introduce:

• quoting/path resolution problems
• extra shell output on stdout/stderr
• encoding differences
• loss of direct stdio semantics between client and Codex

For a JSON-RPC-over-stdio subprocess, shell: true seems especially unsafe on Windows.

Relevant upstream documentation:
The official app-server README says:

• default transport is stdio://
• stdio transport is newline-delimited JSON (JSONL)
• clients must send initialize, then initialized
• RUST_LOG controls tracing verbosity
• LOG_FORMAT=json emits app-server tracing logs to stderr

Reference:
https://raw.githubusercontent.com/openai/codex/main/codex-rs/app-server/README.md

Minimal upstream validation I ran:
codex debug app-server send-message-v2 "Reply with exactly OK."

This was enough to prove that in the same machine/account:

• codex app-server starts
• handshake completes
• a thread and turn can run
• response is returned successfully

Suggested areas to investigate:

1. Remove shell: true from the Windows spawn path for codex app-server
2. Spawn the real Codex executable directly instead of going through shell wrappers
3. Ensure broker stderr is always captured and persisted
4. Inject and preserve:
   • RUST_LOG=debug
   • LOG_FORMAT=json
     for debugging broker/app-server startup
5. Verify stdout is treated as JSONL transport only, and stderr is never mixed into the JSON parser
6. Check whether the broker is exiting before writing broker.json / broker.pid / broker.log

Related upstream Windows/app-server issues:

• invalid JSON parsed from codex app-server stdout:
  Codex process errored: Codex process is not available codex#6435
• Windows extension app-server startup failures:
  VScode extension error - Codex app-server process exited with code 1 and signal null. codex#6062
• Windows stdio/encoding issue with codex-app-server:
  PowerShell encoding issue on Windows: Chinese characters display as garbled text when using stdio with codex-app-server codex#4498

Repro summary:

1. Install/use Claude Code CLI with codex-plugin-cc
2. On Windows 11, with working codex-cli 0.121.0 and ChatGPT Plus login
3. Run /codex:rescue --fresh <prompt>
4. Observe child agent stuck at “Initializing…” indefinitely
5. Independently run:
   codex debug app-server send-message-v2 "Reply with exactly OK."
6. Observe that Codex app-server itself works, pointing to plugin-side broker/spawn/transport handling

[omgoshjosh]

I am sorry if this is against etiquette but I'm also experiencing this. Claude said this: Still showing direct startup mode — no shared runtime active. That's likely
why it hangs: every dispatch tries to cold-start the runtime inline and
blocks.
The codex CLI needs a TTY to start interactively (stdin is not a terminal
confirms this). The plugin expects a warm shared runtime but there's no way to
start it headlessly from here.