Codex App enters restart loop when a local plugin MCP handshake fails

Codex Desktop Restart Loop After Local Plugin MCP Handshake Failure

Date: 2026-09-14
Severity: High
Status: Contained by uninstalling the test plugin

Environment

• Codex App: 26.908.4834.0 x64
• Subscription: not provided
• OS: Microsoft Windows NT 10.0.26200.0 x64
• Plugin: skill-capability-workbench@skill-workbench-dev version 0.1.0
• MCP server: local stdio server named skill_workbench_bridge

What happened

After the local plugin was installed and a Codex task attempted to load it, the
desktop app repeatedly restarted. New desktop log files and process instances
appeared approximately every 20–25 seconds between 16:04 and 16:10 China
Standard Time.

The repeated failure recorded by Codex was:

MCP client for `skill_workbench_bridge` failed to start: MCP startup failed:
handshaking with MCP server failed: connection closed: initialize response:
connection closed: initialize response

The MCP server was retried several times for the same task and for newly opened
tasks. A recoverable MCP startup failure was followed by repeated whole-app
starts instead of remaining isolated to the failing server.

Reproduction

1. Install and enable a local Codex plugin containing the supplied
   skill_workbench_bridge stdio MCP server.
2. Start a fresh Codex task so the plugin is loaded.
3. Observe the server transition from starting to failed during the MCP
   initialize handshake.
4. Observe Codex desktop restart and repeat the same sequence.

The plugin source remains in this repository, but the installed plugin has been
removed to prevent accidental reproduction.

Expected behavior

If one plugin MCP server exits or fails its initialize handshake, Codex should
mark that MCP server unavailable, show a bounded error, and keep the desktop app
and unrelated tasks running. It should not restart the entire desktop app or
enter an unbounded retry loop.

Plugin-side contributing condition

The bridge currently resolves CODEX_THREAD_ID and CODEX_SESSION_ID before
connecting its MCP transport. If either variable is absent, it exits with code
1 and writes:

skill-workbench bridge failed: Codex host task identity is unavailable

An isolated process test proves this exit is deterministic without those
variables. The same server completes MCP connection and its end-to-end tests
when both variables are present and equal. Codex desktop logs do not capture the
server stderr, so the logs establish the handshake failure but do not prove
whether missing environment-variable forwarding was the exact child-process
cause.

The plugin will be changed to connect first and fail softly at tool-call time;
missing task identity must never terminate the MCP server.

Containment completed

• Removed skill-capability-workbench@skill-workbench-dev from the installed
  plugin list.
• Confirmed skill_workbench_bridge is absent from codex mcp list.
• Confirmed no matching Node bridge process remains.
• Preserved all project source and Git history for offline diagnosis.

Host-side safety request

Codex desktop should isolate MCP startup failures and cap retries. A malformed,
misconfigured, or abruptly exiting third-party MCP server must not be able to
restart the whole application repeatedly.

Related project evidence

• docs/feasibility/current-session-bridge.md
• tests/e2e/current-session.spec.ts

Read docs/feasibility/current-session-bridge.md and inspect the desktop MCP startup and retry handling described by the issue. Run tests/e2e/current-session.spec.ts, then trace the failure path from a failed initialize handshake. Done means a failed or exiting plugin MCP server is isolated, retries are bounded, and the desktop app and unrelated tasks remain running.