codex - 💡(How to fix) Fix Managed app-server daemon repeatedly resets remote-control WebSocket; direct app-server stays stable

Summary

The managed Codex app-server daemon appears to repeatedly replace or restart the remote-control app-server, disconnecting all attached Codex CLI/TUI clients with a WebSocket reset. Bypassing the managed daemon / pid-update-loop layer and running codex app-server --remote-control --listen unix:// directly under a user LaunchAgent has kept the same app-server process stable for more than 7 hours.

Environment

• Codex CLI: codex-cli 0.132.0
• Platform: macOS 26.4.1 build 25E253
• Kernel: Darwin 25.4.0 arm64
• App-server socket: unix:///Users/<user>/.codex/app-server-control/app-server-control.sock
• Remote-control app-server command: codex app-server --remote-control --listen unix://

Symptom

Multiple active Codex CLI/TUI sessions were disconnected at the same time with:

remote app server at `unix:///Users/<user>/.codex/app-server-control/app-server-control.sock`
transport failed: WebSocket protocol error: Connection reset without closing handshake

The relevant log entries included:

2026-05-21T15:56:04.702327Z WARN codex_tui::app::app_server_events:
app-server event stream disconnected: remote app server at `unix:///Users/<user>/.codex/app-server-control/app-server-control.sock`
transport failed: WebSocket protocol error: Connection reset without closing handshake

2026-05-21T16:06:50.608800Z WARN codex_tui::app::app_server_events:
app-server event stream disconnected: remote app server at `unix:///Users/<user>/.codex/app-server-control/app-server-control.sock`
transport failed: WebSocket protocol error: Connection reset without closing handshake

2026-05-21T16:12:51.902492Z WARN codex_tui::app::app_server_events:
app-server event stream disconnected: remote app server at `unix:///Users/<user>/.codex/app-server-control/app-server-control.sock`
transport failed: WebSocket protocol error: Connection reset without closing handshake

The disconnects affected multiple CLI/TUI clients simultaneously, which points to the shared app-server process rather than a single client session.

Observations Before Workaround

While the issue was happening, the managed daemon process was present:

codex app-server daemon pid-update-loop
codex app-server --remote-control --listen unix://

The app-server PID changed repeatedly. A local watchdog observed stale or missing app-server PID files and repaired the server repeatedly. Examples:

2026-05-21 23:16:21 CST repair_start reason=stale_or_missing_app_server_pid:62317
2026-05-21 23:27:14 CST repair_start reason=stale_or_missing_app_server_pid:78671
2026-05-21 23:35:51 CST repair_start reason=stale_or_missing_app_server_pid:80766
2026-05-21 23:47:13 CST repair_start reason=stale_or_missing_app_server_pid:89321
2026-05-21 23:49:55 CST repair_start reason=stale_or_missing_app_server_pid:96332
2026-05-22 00:01:18 CST repair_start reason=stale_or_missing_app_server_pid:6497

In one concrete case:

• The app-server PID changed to 11510, started at 2026-05-22 00:06:50 CST.
• That matched the client-side disconnect at 2026-05-21T16:06:50Z / local 2026-05-22 00:06:50 CST.
• The parent process at the time was the managed pid-update-loop, not the custom watchdog.

Workaround That Stabilized It

I stopped using the managed daemon / pid-update-loop path and instead ran the remote-control app-server directly under a user LaunchAgent:

codex app-server --remote-control --listen unix://

Current stable state after the workaround:

PID: 18272
PPID: 1
Start time: Fri May 22 00:14:52 2026
Elapsed: more than 7 hours
Command: codex app-server --remote-control --listen unix://

Health check:

{"status":"running","socketPath":"/Users/<user>/.codex/app-server-control/app-server-control.sock","cliVersion":"0.132.0","appServerVersion":"0.132.0"}

After switching to the direct LaunchAgent:

• codex app-server daemon pid-update-loop is no longer running.
• The app-server PID has remained unchanged for more than 7 hours.
• There have been no new Connection reset without closing handshake entries after the cutover.
• Multiple CLI/TUI sessions have remained attached.

Expected Behavior

The managed app-server daemon should not restart or replace the app-server process during active remote-control / CLI/TUI sessions. If a restart is necessary, clients should be reconnected cleanly or the daemon should preserve active event streams.

Actual Behavior

When the managed daemon / pid-update-loop path was active, all connected clients were periodically disconnected by a WebSocket reset. Running the same app-server command directly without pid-update-loop has been stable.

Suspected Area

The issue appears to be in the managed local app-server daemon lifecycle, especially codex app-server daemon pid-update-loop, rather than in the app-server protocol itself or in a single CLI/TUI client.