Prove persistent Codex Lab engine behind official Mac and iOS clients

[shiny-code-bot]

Objective

Prove the final Codex Lab desktop architecture without building or cloning a GUI: a persistent, provenance-verified Codex Lab engine runs independently of the official clients; the signed ChatGPT macOS app connects to it locally, and the official iOS app connects to the same engine through native remote control.

The engine owns durable sessions, projects, account selection, five-hour and five-day reset awareness, prompt-cache affinity, approvals, and remote enrollment. The official Mac and iOS apps remain replaceable controllers. A ChatGPT app restart or update must reconnect to the same Lab engine rather than silently executing through bundled Codex.

Finish Line

Stock ChatGPT Mac and iOS clients use one persistent provenance-verified Codex Lab engine across client restart and update without silent bundled-Codex fallback.

Current Status

State: Waiting post-release controller-parity track under #498. The persistent engine, official Mac/iOS control path, same-thread continuation, supervisor, provenance, reconnect, and rollback foundations remain proven.

#570 completed the Background Review daily-dogfood reliability gate through PR #579 on August 7. Remote Background Review is therefore no longer waiting on that implementation work. The remaining issue scope is current installed-release evidence for the broader controller matrix: search and structured input, browser/computer-use classification, execution-account lifecycle, and real app update/relaunch continuity.

Next action: after #573 installs the private-release candidate, run one provenance-verified Mac/iOS session that exercises Background Review visibility plus the remaining independent controller checks without bundled-Codex fallback.

Blocked by: no native whole-issue dependency.

Waiting for: the installed private-release candidate and real controller opportunities.

Last verified: August 10, 2026.

Relationships

• Child canary of Dogfood Codex Lab through ChatGPT GUI remote access #365.
• Builds on the split control/execution authentication implementation in Prove stable native remote control with separate execution auth #381.
• Feeds the end-to-end remote workflow validation in Validate Codex Lab remote control through ChatGPT GUI #367 and the daily-driver gate in Run bounded Codex Lab primary daily-driver canary #382.
• Related to Codex Lab identity and channel naming #4 for visible Codex Lab identity and provenance signaling.
• Retains Update Codex Lab launcher for current ChatGPT.app integration #366 only as historical launcher evidence and emergency rollback material, not as the target architecture.
• related: Prove stable native remote control with separate execution auth #381 - Prove stable native remote control with separate execution auth #381
• related: Codex Lab identity and channel naming #4 - Codex Lab identity and channel naming #4
• related: Update Codex Lab launcher for current ChatGPT.app integration #366 - Update Codex Lab launcher for current ChatGPT.app integration #366
• related: Make Background Review trustworthy for daily dogfood #570 - Make Background Review trustworthy for daily dogfood #570

Validation

1. Headless daemon lifecycle and provenance checks in an isolated Codex Lab home.
2. Direct Unix control-socket initialize, version, and reconnect probes.
3. Stock Mac controller canary against the persistent engine.
4. Stock iOS pairing, thread continuation, approval/input, reconnect, and revocation canary.
5. Project/worktree, terminal/file, browser, and computer-use parity matrix.
6. Split-auth quota/failover and prompt-cache accounting checks when an alternate account has usable quota.
7. ChatGPT quit/relaunch, staged-update, daemon crash, login, and reboot recovery tests.
8. Fail-closed tests for missing, corrupt, stale, and protocol-incompatible Lab engines.

Decisions

• The official ChatGPT Mac and iOS clients remain the only user-facing work surfaces.
• Codex Lab becomes a persistent engine/service, not a replacement GUI.
• The Mac path should be local and low-latency; iOS uses native remote control to the same engine.
• Launcher/menu-bar work is skipped unless a concrete canary failure proves an external recovery surface is necessary.
• Configuration is never accepted as proof of runtime identity; only live provenance from the serving engine can establish Lab status.
• Updates must reconnect to the persistent engine and must never silently switch execution to bundled Codex.

Open Questions

• Does the current stock Mac client preserve all local-host capabilities when connected through the existing local-daemon socket path?
• Can Lab identity and provenance be surfaced through the native host/environment UI, or is a minimal error-only status utility ultimately required?
• Which desktop/iOS app-server protocol changes require compatibility shims or coordinated Lab updates?
• Which native computer-use and browser host services must be bridged into the persistent daemon?

Acceptance Criteria

• A fixed Codex Lab engine starts from an immutable, provenance-verified candidate and cannot update itself to an upstream official binary.
• The current stock Mac client initializes against the engine over local websocket transport while preserving local-host semantics.
• The paired iOS client initializes against the same engine through native remote control.
• The Mac and iOS clients can observe and continue the same thread without duplicate turns or lost output.
• Existing projects and worktrees can be opened or mapped without accidental execution on the bundled Local host.
• Terminal streaming, file reads/edits, search, command/file approvals, and structured user input work from both relevant controllers. File reads and native iOS command approval are proven; search, structured input, and the full controller matrix remain.
• Browser use and native computer use are explicitly proven or recorded as a blocking parity gap.
• Control account identity remains stable while eligible execution accounts rotate only at safe turn boundaries and preserve per-thread cache affinity.
• ChatGPT quit/relaunch and one real in-app update reconnect to the same engine without re-pairing or bundled-Codex fallback.
• Engine absence and provenance failure are visible and fail closed; required V8 JIT entitlement validation is now merged, while client/engine protocol incompatibility remains to be exercised explicitly.
• A durable supervisor recovers the engine after crash, login-equivalent reload, and reinstall without launching ChatGPT automatically.
• Rollback restores the previous Lab engine or intentionally returns to stock Codex without stale launchd state.

[cbusillo]

July 21 Mac canary evidence

The final-form Mac transport is now proven against the stock signed ChatGPT app.

Live state

• Persistent engine: ~/.codex-lab/packages/standalone/current/codex
• Engine signature: Developer ID, fixed identifier com.shinycomputers.codex-lab.engine
• Daemon PID: 86648
• GUI PID: 87188
• Socket: ~/.codex-lab/app-server-control/app-server-control.sock
• Remote control: enabled in place after local connection

Stock GUI evidence

From codex-desktop-265abc52-d084-4231-8f60-ac2505795d41-87188-t0-i1-225539-0.log:

Transport start success ... hostId=local transport=websocket
Current reported app-server version: currentVersion=0.0.0 hostId=local
initialize_handshake_result durationMs=3 ... outcome=success transportKind=websocket
... next=connected ... hostId=local ... transport=websocket

Process inspection showed only the managed daemon app-server. No ChatGPT-bundled or legacy candidate stdio app-server existed, and the GUI log contained no SQLite initialization failure.

Root causes resolved in the canary

1. InitializeResponse.userAgent had reused the outbound compatibility-clamped user agent, reporting 0.120.0; ChatGPT 26.715.70719 requires >=0.141.0 or the exact 0.0.0 development sentinel.
2. A freshly built engine had a different ad-hoc CDHash and therefore could not read the existing encrypted-auth Keychain item. Stable Developer ID signing plus one controlled login status authorization solved this without weakening Keychain access.
3. Full app-server startup generated many concurrent prompts against one item. The controlled preflight generated exactly one prompt and future reads were silent.
4. Earlier automated rollbacks after successful connections were verifier bugs: the desktop first logs an initial transport=stdio placeholder, then reports the selected local daemon as transport=websocket. Final-state logs, not the initial placeholder, are authoritative.

Remaining release work

• Integrate stable engine signing and the one-request Keychain preflight into packaging/install.
• Preserve/fail closed on signing identifier and Team ID mismatch.
• Prove quit/relaunch and a real stock-app update reconnect without special manual launch state.
• Complete same-thread Mac/iOS continuation, approval/input, and reconnect tests.

[cbusillo]

iOS remote-control canary passed — July 21, 2026

The persistent signed Codex Lab daemon successfully paired with the official ChatGPT iOS client while the desktop GUI remained attached over the local WebSocket transport.

Verified directly through app-server RPC:

• designated primary account was active for the control plane
• remoteControl/status/read returned connected
• the manual pairing artifact returned claimed: true
• remoteControl/client/list returned one authorized phone / ios client
• client identified itself as ChatGPT iOS 1.2026.188
• the client and daemon were attached to the same account-scoped environment

Important implementation finding: account/switchActive updates the shared auth manager, but an already-connected remote-control WebSocket does not currently terminate on the auth-change notification. For this canary, cycling remoteControl/disable then remoteControl/enable forced a clean relay re-authentication and produced a new environment for the designated control identity. The final architecture should establish the fixed control identity before starting the relay—or explicitly reconnect the relay when its control identity changes—while execution-account selection remains independent.

[cbusillo]

Official iOS local-mode canary passed — July 22, 2026

The first complete official-GUI + official-iOS local-control path is now proven end to end.

Root cause of the earlier mobile rejection:

• the local development package was built without CODE_VERSION
• remote enrollment therefore advertised app_server_version = 0.0.0
• the desktop initialize response also advertised 0.0.0
• pairing authorization could succeed, but the mobile client correctly displayed “update desktop app to connect” and withheld local mode

Canary remediation:

• rebuilt the same Codex Lab source with CODE_VERSION=0.145.0-alpha.27, matching the Codex binary bundled in the installed official desktop application
• signed it with the stable Codex Lab Developer ID requirement
• backed up state, removed only the stale primary-control-account enrollment, installed the versioned binary, and restarted the persistent daemon
• backend re-enrollment reused the existing environment and preserved the authorized iPhone
• desktop GUI reconnected over WebSocket and reported app-server 0.145.0-alpha.27

Observed iOS proof:

• user selected the local host and sent REMOTE CANARY 1
• Codex Lab created a local thread and persisted the exact user message
• the model returned Codex Lab active. Remote canary 1 acknowledged.
• a direct thread/read RPC against the persistent daemon returned both the user and agent messages and reported the thread idle

This closes pairing, authorization, mobile version compatibility, remote thread creation, remote prompt delivery, model execution, response persistence, and desktop-daemon continuity for the single fixed control identity. Remaining decisive gate: keep this remote control identity fixed while assigning execution for a subsequent turn/thread to a different stored account.

Packaging follow-up: release/dev installers must always inject explicit CODE_VERSION; 0.0.0 is not a valid remotely usable package identity. The top-level CLI --version path still reports the Cargo workspace version and should be reconciled with build provenance separately.

[cbusillo]

Fixed-control / pooled-execution canary passed

The remaining architectural gate from the prior comment passed in the same REMOTE CANARY 1 run.

Direct evidence:

• thread/start arrived from codex_chatgpt_ios_remote version 1.2026.188
• the daemon's active account remained the designated primary remote-control identity
• session initialization logged resolved execution account lease for a different stored account
• the persisted execution-account lease for the remote-created thread matches that secondary account
• gpt-5.6-luna completed the turn and the response was returned to/persisted for the iOS-created thread
• a direct thread/read returned both REMOTE CANARY 1 and Codex Lab active. Remote canary 1 acknowledged.

Therefore the canary proves this topology:

official ChatGPT iOS
        │ fixed primary control identity
        ▼
OpenAI remote-control relay
        │
        ▼
persistent Codex Lab app-server
        │ independent per-thread execution lease
        ▼
secondary stored execution account

This is the core product result: official desktop GUI and official iOS remote control can remain stable on one account while Codex Lab selects another paid account for model execution. Remaining work is production hardening rather than architectural feasibility: release-version injection, update/restart continuity, quota/reset-aware selection, stable same-thread affinity for prompt caching, and controlled failover tests.

[cbusillo]

Same-thread affinity and mobile task-stream recovery passed

After the first successful remote turn, the iOS task view entered Reconnecting to task and disabled Send.

Diagnosis:

• persistent daemon remained running
• remote-control relay remained connected
• environment and pairing authorization remained unchanged
• the iPhone continued reporting presence
• the remote-created thread was intact, idle, and readable through app-server RPC
• during a 90-second trace, the iOS task view sent no task-stream reconnect request to the host

Recovery:

• cycled only remoteControl/disable → remoteControl/enable
• did not restart the daemon or desktop GUI
• did not change the control account, environment id, thread, or execution lease
• did not require re-pairing
• reopening the existing task restored the Send control

Follow-up proof:

• iOS sent REMOTE CANARY 2 in the original thread
• Codex Lab returned Codex Lab active. Remote canary 2 acknowledged.
• direct thread/read reported two turns and all four expected user/agent messages
• the primary control identity remained active
• the persisted secondary execution-account lease was unchanged
• the iPhone remained usable with Send enabled after the second response

This validates stable same-thread execution affinity—the behavior needed to avoid gratuitous account switching and preserve prompt-cache locality. It also establishes a narrow recovery primitive for a stale mobile task view: relay-only reconnect, with no daemon/session/pairing disruption.

Production hardening should detect this stale-task condition and perform or offer the relay-only recovery automatically rather than leaving the mobile UI indefinitely disabled.