Skip to content

Prove stable native remote control with separate execution auth #381

Description

@shiny-code-bot

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 historical Lab remote-control/account-isolation evidence. The old installed runtime is retired.
Next action: use #974/#975 for current iPhone access to CLI-started work. Reuse this issue's old canary only if a demonstrated kept need calls for that evidence.
Waiting for: a concrete fresh-route gap needing the old evidence. The previous installed-release and account-pool architecture is not a prerequisite to the current remote milestone.
Multiple accounts remain a later journey need under DIRECTION.md; this status does not change credentials or login flows.
Last verified: 2026-09-26. Historical canaries remain dated and are not current installed-product proof.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:donePlan completed or superseded

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions