[IDE extension][Linux] bundled app-server 0.146.0-alpha.3.1 repeatedly exits with SIGILL and does not recover

Summary

The Codex app-server bundled with the current stable VS Code extension repeatedly exits with signal=SIGILL during long IDE sessions. After the native exit, the extension does not restart it and keeps attempting to write to destroyed stdin, so the Codex panel appears hung until the extension host is restarted.

This is the app-server process itself, not the VS Code renderer. I found 14 distinct [CodexMcpConnection] ... signal=SIGILL events between 2026-07-26 and 2026-07-29.

Environment

• VS Code Remote / devcontainer on WSL2
• Guest OS: Debian 12 (bookworm), x86_64
• Kernel: Linux 6.6.87.2-microsoft-standard-WSL2
• VS Code: 1.131.0 (e4c7e7b1d6d060162f4aa7f8225271b67ce1df75)
• Stable Codex extension: openai.chatgpt 26.721.41059
• Extension metadata: preRelease=false
• Extension-bundled Codex CLI: 0.146.0-alpha.3.1
• Standalone CLI on PATH: 0.133.0 (not the process that crashes)

Representative timeline

In one occurrence:

1. A Playwright command started at 17:52:44.
2. The command's durable log shows that it finished at 17:52:53 with two ordinary screenshot mismatches.
3. At 17:52:57, the extension logged:

[CodexMcpConnection] Codex process fatal error
Codex app-server process exited unexpectedly (code=unknown, signal=SIGILL)

1. Subsequent extension attempts repeatedly logged:

Attempted to send app-server message but stdin is destroyed
Codex process is not available

1. The extension did not recover until the extension host was restarted. The terminal/process session was already gone when the chat resumed later.

The external command had completed before the native app-server exit, so this occurrence was not a hung Playwright process.

Pattern across the 14 crashes

The Last CLI error varies significantly between crashes and appears incidental rather than causal. Examples include:

• an earlier apply_patch context mismatch;
• OAuth/keyring warnings;
• state DB discrepancy warnings;
• a missing local image path;
• WebSocket reset/closed-normally retries.

Several crashes follow response-stream interruptions. One occurrence logged:

Responses websocket connection limit reached (60 minutes). Create a new websocket connection to continue.

and the app-server exited with SIGILL about 20 seconds later. Other occurrences followed Connection reset without closing handshake or Connection closed normally retries.

Aggregate sanitized counts from 27 recent extension logs:

• app-server SIGILL: 14
• Item not found in turn state: 576
• stream disconnected - retrying: 49
• state db discrepancy: 310
• Failed to release send lock: 6

The heaviest affected conversation lasted almost five hours and generated a 46 MB rollout with hundreds of tool calls and several context compactions. This may increase exposure, but shorter sessions have also shown the same native signal.

Expected behavior

• A stream reconnect or 60-minute WebSocket rollover should create a new connection without terminating the app-server.
• If the app-server does exit, the extension should restart it or present a bounded recovery action instead of repeatedly writing to destroyed stdin.
• The extension should preserve/reconcile the current turn state after recovery.

Actual behavior

The bundled app-server exits with SIGILL; the extension remains permanently degraded and visually appears stuck. Waiting does not recover it.

Current workaround

• Restart the VS Code extension host.
• Continue in a new, smaller chat instead of resuming the multi-hour turn.
• Recover external command results from durable logs rather than relaunching them blindly.
• I am testing the immediately previous stable extension (26.721.30844), whose bundled CLI is 0.146.0-alpha.3 rather than 0.146.0-alpha.3.1.

No raw rollout or full extension log is attached because those files can contain workspace source and tool arguments. I can provide a further sanitized excerpt or run a diagnostic build if useful.