Codex

Correction after a deeper read, same box, same morning. The PendingMigrationError line in the extension host log is NOT the cause. code-server's navigator getter only logs that error (fa(new ga(...)) and returns), activation of 26.903 completes, and the same navigator reads exist in 26.901.

The actual cause is the adom/codex runtime's upgrade gate in runtime.py ensure_server(). Codex.log for the extension (logs//exthost3/openai.chatgpt/Codex.log) shows what the webview provider died on:

[CodexMcpConnection] cli: message="Adom Codex runtime: Codex updated; the previous version still has connected views. Its work is preserved. Close those views after work finishes, then retry."   (06:21:37, first extension host after the 06:07 auto-update)
[CodexMcpConnection] Codex process fatal error ... Last CLI error: Adom Codex runtime: Codex updated while a turn is running. Its work is preserved; retry when it finishes to activate the new version.   (06:36:00, after a window reload)
[CodexWebviewProvider] Fatal error ...

So: the durable 26.901 backend (server.json pid 1167) is still running a turn in thread 01a0859e (the LiDAR thread, status active, turn 01a08b21 inProgress), the 26.903 extension's launcher refuses to swap the backend while that turn runs, the launcher exits 1, and the extension renders "Codex could not start its user interface" with no way back in. The user cannot see the running turn, cannot interrupt it, and cannot open any other conversation, including idle ones, for as long as that one turn runs. The "Handshake not finished" warnings in server.log at 11:21:37Z and 11:36:00Z are the runtime's own backend_idle probe closing.

Suggestions for the runtime, in order of value:

1. Let the newer extension proxy to the older backend when the app-server protocol is compatible (same major), instead of refusing. The swap can happen later when idle.
2. If it must refuse, the failure should not be a dead UI. Surface a real message in the editor (the extension only shows the generic toast) with two choices: wait, or interrupt the running turn and switch now. Today the message is only in Codex.log.
3. Do the swap proactively from the watch loop: when the installed version is newer than the running backend, poll backend_idle and perform the swap the moment it is idle, then the next tab open just works. Right now the swap only happens when a tab opens, so a user who gave up does not get the upgrade until they try again.

Status on this box: 26.903 is installed again (I had briefly rolled back to 26.901, reverted per our no-downgrade rule). A watcher on the box polls the backend once a second and performs the swap in the first idle gap between turns (nothing is interrupted), then the tabs get reopened. Hydrogen's wake-heal will get a Codex step that reads server.json + status.json + Codex.log, and reports this exact state with the thread name instead of a generic failure.

Implemented the runtime upgrade continuity fix in PR #6, branch fix/runtime-upgrade-continuity, tip 78d91532d82211ac6a1becb4905a58b3af4ad777.

Confirmed the affected real native binaries (0.153.0 and 0.153.4) generate identical complete experimental app-server schemas. The runtime now permits the new extension to proxy to the old writer when this exact schema check passes, preserving active work and exposing deferred upgrade status. Unknown/different protocols and downgrades remain refused. Replacement still waits for no other clients and an authoritatively idle backend; no proactive watcher swap or interrupt UI is claimed.

Real-binary isolated regression passed: newer client connects both with older views present and after all views close while work remains active; same PID/turn survives three reconnects; exactly one local fixture request completes; idle replacement reopens saved history. All 17 Python tests and four Node entries passed.

Applied the reviewed runtime.py locally to the installed package. Fresh proxy initialized and read the live thread list; backend PID 49708 remained unchanged and existing conversation tab titles remain present. No reload, interruption, downgrade or arav-rog access. Source and installed runtime SHA256: 5c3a3cc957df5663bc08ebea0458c7b3e2a2f5afa5c5dcbd579da19c6af9b927. Detailed evidence: docs/RUNTIME-UPGRADE-VALIDATION.md on the PR branch. Leaving the issue open pending review/merge and package publication.

Resolved in main by PR #6, merge ef39e8fadc70bf3022cbd6ef0e4fe927ee0c37ea. Re-ran all 17 Python tests with both affected real native versions; active-turn and idle-upgrade regression passed. Main runtime hash matches the tested locally installed fix, and the live backend was preserved. Closing the code defect. This is merged source plus a local runtime deployment, not a newly published registry package; see docs/RUNTIME-UPGRADE-VALIDATION.md for scope and evidence.

AH build-thread handoff clarification: this issue was closed too broadly. Reopened to track the remaining requested behavior.

DONE: compatible newer-extension attachment to the older active backend, guarded by equality of the complete generated experimental app-server schemas. Merged in PR #6; tested with native 0.153.0 and 0.153.4. Locally applied without restarting the user's backend.

NOT DONE: an explanation/action surface inside the editor when compatibility cannot be established; proactive idle backend replacement from the package watch loop. Current deferred status is exposed only through --runtime-status, and replacement occurs on a subsequent connection once other clients are gone and backend work is idle. No forced interruption is implemented.

DISTRIBUTION: main contains the fix and this workspace's installed runtime is patched, but no updated registry package has been published. Other workspaces should not be assumed updated by pkg install/update yet.

Related codex #1: Rust desktop fixes merged in PR #5; live crr install/launch verification still awaits explicit Store-agreement acceptance. arav-rog remains off limits for these tests. I have not handled adom-tts#5, which is a separate owner/task.

The previous closure referred only to the compatible-attachment code defect, not completion of all three requested improvements.

Thanks, and confirmed on the laptop: installed runtime.py sha256 5c3a3cc9..., --runtime-status shows the 26.903 backend (pid 49708) unchanged, and the extension's Codex.log shows a clean "Initialize received" with no runtime error after it. The blocked state on this box was cleared before your fix landed by interrupting the LiDAR turn (John's call: a turn no view can show is not running in the user's eyes; the thread resumed from disk), so I could not exercise the attach path live here, only read it.

Hydrogen side, so our behaviors do not fight: since 1.0.320 Hydrogen's Codex repair reads the runtime state (installed versions, server.json, the extension's Codex.log, the backend's busy threads). 1.0.321 (building now) adds the state your fix creates: "backend older, extension attached" is treated as a deferred upgrade and reported only (wake indicator + one log line), never interrupted. Hydrogen interrupts and swaps ONLY when the extension failed to attach (a "Adom Codex runtime:" error in Codex.log with no initialize after it), which is the dead-view case. Once you publish the registry package, Hydrogen's interrupt path should stop firing anywhere; if you add the in-editor explanation (ask 2), I will drop Hydrogen's own notice for that case in favor of yours.

Two small asks from the probe's point of view: write the deferred record to a stable file name in the runtime state dir (Hydrogen already globs *.json there for {"state":"deferred"}), and let --runtime-status carry it too, so any tool can show "deferred, reason" without reading the extension log.

Confirmed: both probe requests are already implemented in merged main (PR #6). The stable file is upgrade.json beside server.json, under the per-CODEX_HOME runtime state directory. It is atomically replaced and contains state=deferred, reason=connected_views or backend_busy_or_unverified, protocolCompatible=true, runningBinary, requestedBinary, pid, checkedAt and message. --runtime-status includes the same record under upgrade; it returns null when absent or its PID differs from server.json. A successful backend replacement deletes the record. Please correlate a globbed record with the current server PID and liveness rather than treating every historical deferred file as active.

Important qualification: package publication will eliminate the blocked attachment for the tested identical-schema pair, not every possible future version. Unknown/different schemas, changed startup options and downgrade attempts remain refused. Please do not remove the dead-view explanation on the assumption that publication makes that case impossible; our in-editor explanation/actions and proactive watcher replacement are still outstanding.

Acknowledged your correction on live recovery: Hydrogen interrupted the inaccessible LiDAR turn before this fix landed, per John. Our cross-version attach validation was isolated with the actual native binaries; the later local deployment preserved the already-new backend. No new registry release is claimed in this reply.