[VS Code Remote-SSH] bundled app-server drops initialize sent immediately after spawn

What version of the IDE extension are you using?

openai.chatgpt@26.908.40401 (Release); bundled codex-cli 0.154.0-alpha.6.2

What subscription do you have?

API key authentication (not a ChatGPT subscription; key and provider endpoint redacted)

Which IDE are you using?

VS Code Remote-SSH; VS Code Server 1.137.0; remote Extension Host Node v24.18.1

What platform is your computer?

macOS client; Linux x86_64 remote host (hostname redacted)

What issue are you seeing?

In a VS Code Remote-SSH window, the Codex sidebar keeps loading indefinitely. The same extension and Codex configuration work in a local macOS VS Code window.

The extension successfully spawns its bundled app-server with:

codex -c features.code_mode_host=true app-server --analytics-default-enabled

The process remains alive, but the extension never records a successful app-server initialization. The webview sends repeated initialization requests and the extension log records each one being discarded:

Initialize received id=CodexWebviewProvider.webview:...
Dropping MCP message received before initialization

A related broadcast also arrives before a handler is configured:

[IpcClient] Received broadcast but no handler is configured
method=client-status-changed

No app routes are mounted, so the sidebar never reaches the usable UI.

A controlled test with the original bundled ELF (not a wrapper) shows startup-timing sensitivity: sending initialize immediately after spawning the stdio process can produce no response, while delaying the first initialize until the server has completed early startup returns the normal initialization response. A non-blocking compatibility gate that buffers only the first request until startup is ready restores the sidebar; both normal window reload and a full VS Code cold start were verified.

This appears inconsistent with the documented lifecycle: the client is instructed to send initialize immediately after opening the transport connection. See https://learn.chatgpt.com/docs/app-server#initialization.

What steps can reproduce the bug?

1. Connect from macOS to a Linux host using VS Code Remote-SSH.
2. Install/enable the Release build of the Codex extension on the remote Extension Host.
3. Open the Codex sidebar.
4. Observe that the bundled app-server starts and remains alive, but the sidebar keeps loading.
5. In the Codex extension log, observe repeated Initialize received entries followed by Dropping MCP message received before initialization.
6. Reproduce against the original bundled executable over stdio while keeping stdin open:

const child = spawn(BUNDLED_CODEX, [
  "-c", "features.code_mode_host=true",
  "app-server",
  "--analytics-default-enabled"
], { stdio: ["pipe", "pipe", "pipe"] });

child.stdin.write(JSON.stringify({
  method: "initialize",
  id: 1,
  params: {
    clientInfo: {
      name: "codex_vscode",
      title: "Codex VS Code Extension",
      version: "26.908.40401"
    }
  }
}) + "\n");
// Keep stdin open and read stdout with a bounded timeout.

7. Compare an immediate write with the same request held briefly until early app-server startup finishes. The immediate request may receive no response; the delayed request completes initialization.

No hostname, project path, provider URL, API key, token, or account detail is included in this report.

What is the expected behavior?

The bundled app-server should reliably accept or buffer the first initialize request sent immediately after the stdio transport is opened, as specified by the official protocol documentation.

It should not silently lose the only initialization request because its internal request handler is not ready yet. If an early request cannot be accepted, the server should expose a readiness signal or return an explicit protocol error. As defense in depth, the IDE extension could also retry or restart after a bounded initialization timeout instead of leaving the sidebar loading indefinitely.

Additional information

Environment:

• Codex extension: openai.chatgpt@26.908.40401 (Release)
• Bundled CLI: 0.154.0-alpha.6.2
• VS Code Server: 1.137.0
• VS Code Server commit: 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
• Remote Extension Host Node: v24.18.1
• Authentication: API key (secret omitted)
• Transport: local stdio between the remote Extension Host and bundled app-server

Additional controls:

• The original bundled ELF reproduces the timing behavior; the result is not based on a diagnostic wrapper.
• The app-server process remains alive, so this is not a process crash.
• An earlier Node global-navigator compatibility error was resolved and is absent from the failing startup logs.
• Network access warnings are not treated as the cause: the configured model endpoint is reachable, the same configuration works locally, and delayed initialization succeeds without changing network conditions.
• Switching the extension to a separately installed global CLI is not a valid workaround: it can initialize but leaves later RPCs pending because the versions are not fully compatible.
• This differs from #37521, where app-server initialization succeeds and the startup stalls later on account/identity requests.

Current workaround (not proposed as the product fix): a reversible, non-blocking gate delays/buffers the first app-server request until early startup is ready, then transparently forwards bidirectional stdio.

Start at the bundled app-server entry point and its stdio initialization handling, then reproduce the immediate-versus-delayed initialize test described in the report. Done means the first initialize request is reliably accepted or buffered during startup, with coverage for the early-request timing case and no indefinite VS Code sidebar loading.