Objective
Preserve one stable ChatGPT account as the native ChatGPT Desktop/iOS remote-control identity while Codex Lab maintains a pool of the user's separately paid, explicitly enrolled ChatGPT accounts for model execution. The execution selector should intelligently choose among accounts A, B, and C using each account's own usage/capacity state and configured preferences, while every request remains authenticated to exactly one account and subject to that account's normal enforcement.
Prove that the proprietary clients can remain paired to control account A while remote turns execute under A, B, or C, without cloning the Mac or iOS app, merging account data, falsifying usage, or sending secondary-account credentials through the remote-control transport.
Finish Line
A deterministic integration suite and one isolated native Desktop/iOS dogfood flow prove that control account A remains enrolled, paired, connected, and revocable while Codex Lab automatically selects eligible execution accounts from A/B/C, records which account executed each turn, safely changes execution identity between turns, and preserves the native remote session.
Current Status
State: Waiting post-release native-client hardening; the core fixed-control and pooled-execution architecture is proven.
The July 22 official iOS canary kept the primary remote-control identity stable while a different stored account executed the remote-created thread. The merged implementation and native control path are therefore no longer awaiting architectural feasibility proof. Remaining work is current-release evidence for controller lifecycle coverage, prompt-cache affinity, and controlled failover behavior.
Next action: after private release #573, run one provenance-verified Mac/iOS canary from the installed candidate, complete the remaining approval/reconnect/revoke observations, and record bounded same-thread cross-account cache-affinity or an explicit conservative cache-cold decision.
Blocked by: no implementation dependency.
Waiting for: an installed private-release candidate and eligible account/client conditions.
Last verified: August 10, 2026 against the July 22 canary evidence and current issue graph.
Validation Evidence
Remaining Work
- Re-run the native ChatGPT Desktop → iOS prompt, approval, reconnect, and revoke matrix from the installed private-release candidate.
- Confirm the fixed primary control identity remains paired while an eligible alternate account executes the remote turn; the July 22 canary already proves this architecture and should now be repeated only as release evidence.
- Record bounded same-thread prompt-cache affinity and controlled failover behavior across execution-account selection, or retain an explicit conservative cache-cold decision.
Implementation blocker: none.
Next Action
After #573 installs the private-release candidate, run the remaining native-controller and cache-affinity evidence from that exact build. Keep this issue plan:waiting; it is no longer an implementation or cutover blocker.
Objective
Preserve one stable ChatGPT account as the native ChatGPT Desktop/iOS remote-control identity while Codex Lab maintains a pool of the user's separately paid, explicitly enrolled ChatGPT accounts for model execution. The execution selector should intelligently choose among accounts A, B, and C using each account's own usage/capacity state and configured preferences, while every request remains authenticated to exactly one account and subject to that account's normal enforcement.
Prove that the proprietary clients can remain paired to control account A while remote turns execute under A, B, or C, without cloning the Mac or iOS app, merging account data, falsifying usage, or sending secondary-account credentials through the remote-control transport.
Finish Line
A deterministic integration suite and one isolated native Desktop/iOS dogfood flow prove that control account A remains enrolled, paired, connected, and revocable while Codex Lab automatically selects eligible execution accounts from A/B/C, records which account executed each turn, safely changes execution identity between turns, and preserves the native remote session.
Current Status
State: Waiting post-release native-client hardening; the core fixed-control and pooled-execution architecture is proven.
The July 22 official iOS canary kept the primary remote-control identity stable while a different stored account executed the remote-created thread. The merged implementation and native control path are therefore no longer awaiting architectural feasibility proof. Remaining work is current-release evidence for controller lifecycle coverage, prompt-cache affinity, and controlled failover behavior.
Next action: after private release #573, run one provenance-verified Mac/iOS canary from the installed candidate, complete the remaining approval/reconnect/revoke observations, and record bounded same-thread cross-account cache-affinity or an explicit conservative cache-cold decision.
Blocked by: no implementation dependency.
Waiting for: an installed private-release candidate and eligible account/client conditions.
Last verified: August 10, 2026 against the July 22 canary evidence and current issue graph.
Validation Evidence
Remaining Work
Implementation blocker: none.
Next Action
After #573 installs the private-release candidate, run the remaining native-controller and cache-affinity evidence from that exact build. Keep this issue
plan:waiting; it is no longer an implementation or cutover blocker.