You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
codex app-server proxy hangs on WebSocket-framed initialize while direct Unix socket succeeds #25846
codex app-server proxy --sock <default control socket> appears not to forward a WebSocket-framed initialize exchange even though the same WebSocket handshake and masked text frame works directly against the Unix control socket.
This is related to #23572, but this reproduction does not use Content-Length framing. It uses the framing described in codex-rs/app-server/README.md: WebSocket HTTP Upgrade followed by WebSocket frames.
Environment
Platform: macOS / Darwin arm64
Codex Desktop: 26.527.60818 / build 3437
Desktop-bundled codex: codex-cli 0.136.0-alpha.2
Standalone current codex: codex-cli 0.135.0
codex app-server daemon version:
status: running
backend: pid
managedCodexVersion: 0.135.0
cliVersion: 0.136.0-alpha.2
appServerVersion: 0.135.0
What I tested
I sent the same minimal app-server initialize request over three transports:
Raw Unix socket connection to the default app-server control socket.
~/.codex/packages/standalone/current/codex app-server proxy --sock <default control socket>.
Desktop-bundled codex app-server proxy --sock <default control socket>.
I reduced the proxy behavior reported here to a small no-dependency Node.js
reproducer that sends only initialize over the Unix-socket WebSocket framing
described in the app-server README. It compares the same request bytes through:
a direct connection to the app-server control socket;
codex app-server proxy --sock <same socket>;
$HOME/.codex/packages/standalone/current/codex app-server proxy --sock <same socket>, if that binary exists.
The script deletes common OpenAI/Codex API environment variables for proxy child
processes and prints only a summary. It does not call thread, turn, model,
provider, filesystem, or remote-control APIs.
The output shape that would confirm the proxy-specific failure is:
raw unix socket:
handshake_observed=true
switching_protocols=true
initialize_ok=true
codex app-server proxy:
initialize_ok=false
completion_reason=timeout or no initialize response
Activity
bakemocho commentedon Jun 4, 2026
I reduced the proxy behavior reported here to a small no-dependency Node.js
reproducer that sends only
initializeover the Unix-socket WebSocket framingdescribed in the app-server README. It compares the same request bytes through:
codex app-server proxy --sock <same socket>;$HOME/.codex/packages/standalone/current/codex app-server proxy --sock <same socket>, if that binary exists.The script deletes common OpenAI/Codex API environment variables for proxy child
processes and prints only a summary. It does not call thread, turn, model,
provider, filesystem, or remote-control APIs.
Run:
Optional:
The output shape that would confirm the proxy-specific failure is:
Standalone Node.js reproducer