Skip to content

Separate GUI and phone identity from CLI execution accounts on the fresh start #979

Description

@shiny-code-app

Objective

Keep the owner's GUI/phone identity stable while CLI model execution uses another of the owner's accounts after a rate limit. #975 proved concurrent stock phone/CLI access with matching accounts. The owner reports immediate stops at usage limits and rules out credit top-ups on value grounds, making execution-account switching necessary for dependable remote use.

switch execution accounts after a usage limit without losing local or phone access

This exact phrase from DIRECTION.md, landed by #980 at e1ab370, admits the minimum account-separation work to Remote access on the fresh start.

Finish Line

On the fresh baseline, the owner can keep the GUI/phone control login fixed while choosing a different CLI execution account between turns. The same locally open task remains accessible from the phone and usable locally. Record actual versions, which component owns each login and token refresh, and the upstream files changed. The smallest implementation must preserve normal account authentication and make the selected execution account understandable to the owner.

Current Status

State: implemented, merged, installed and live on the everyday daemon; this session is closed out with remaining acceptance recorded below. All PRs #982 through #992 are merged, and the fresh open-PR inventory is empty. Main and all twelve installed Python files match 91d1bef. The final main Account router run is successful, and #992 is confirmed merged. Full-history issue/PR comment checks found no attention items.

Next action: after this conversation's harness exits normally, adopt and resume its saved task through codex-account-router with execution-a. This final conversation still uses the original openai provider; the other four root sessions are registered with the account selector. No repeat sign-in, pairing, execution enrollment or blanket approval is needed. The exact owner-local rejoin command has been given in the conversation and retained as a convenience; the durable procedure is tools/account-router/README.md (Attach to the everyday daemon). For new routed tasks use start; ordinary stock /new still uses the default provider.

Live evidence: the owner paired the original daemon, opened an existing CLI task and received the requested reply with correct prior-project context. The same completed turn matched the persisted execution-a pin and HTTP 200 receipt while the intended phone/control identity and Remote connection stayed unchanged. The owner confirmed success. At this closeout, the router has continued running under launchd with no restart since activation; Remote is connected, and three registered tasks have successful request receipts. One other task is actively working and was left undisturbed. These later receipts do not replace #976's full three-session qualification.

Remaining acceptance: final current-harness adoption, normal revocation/recovery and a naturally depleted-control condition. Do not manufacture exhaustion or buy credits. #979 remains open and blocks #976, then #977. Automatic rotation in #993 is a separate later-milestone item. The existing 43 focused tests, installed-stock same-ID/history probe, Ruff/repository formatting, GREEN targeted IDE and PR/main CI evidence remain valid. A full Mac reboot remains untested. Current-target background review is not yet observable for source 610ca32; no terminal review outcome is inferred.

Cleanup: removed the finished implementation worktree and all eleven merged local account-router task branches. Their commits are reachable from the verified live main SHA. Preserved and hash-verified all 964 ignored local files (including IDE/environment state) and a Git bundle with the task refs before removal. The recovery group is owned by #979 and retained until its remaining acceptance and local-state retention needs are settled. The generic inventory hit its repository ref_limit; it was not counted as clearance. Removal used a complete focused filesystem traversal, exact-ref ancestry and clean-state checks, verified storage identity, no open IDE project or process reference, and hash-verified preservation. The primary checkout and unrelated worktree registrations were independently verified unchanged.

Also removed 21 consumed installation/observation scripts, draft posting payloads, obsolete prepared copies and expired login/pairing code files. Retained the live service/configuration/selection and all account homes, stopped pilot home/configuration for rollback, current and prior wheels, qualification/phone/runtime/IDE receipts and the exact final rejoin instruction. Retained groups are private and owned by #979; review disposal after remaining acceptance or replacement recovery proof. No watcher, test host or conversation-owned helper remains as a runtime dependency. The installed service imports outside the removed worktree.

Last verified: 2026-09-27 UTC. Main is clean and matches its advertised remote SHA; the runtime is launchd-owned and the original stock daemon remains available. No source edit, release publication, account revocation, unrelated cleanup or full-disk audit was performed during closeout. Repository quality metadata remains applicable; operational commands and limitations are documented in the package README. No owner decision is outstanding for this closeout.

Scope

Solve stable control identity and separate CLI execution identity first. Manual selection between turns is sufficient for this slice; automatic rotation, quota management and the historical Lab account pool are not prerequisites. Prefer supported configuration or a sidecar in this repository; shared instructions belong in the catalog. Any upstream patch must name the capability that cannot be supplied outside Codex.

DIRECTION.md requires an owner decision before changing credentials, account storage or login flows. Design and read-only inspection can precede that decision. Preserve existing sessions and the currently working phone route; plan any disruptive qualification separately.

Acceptance Criteria

  • Record the installed and checked-in boundaries between GUI/phone control authentication and CLI execution authentication; compare only approaches that can meet the same-session requirement.
  • Choose one implementation with explicit ownership of login, token refresh and stored credentials, plus its setup and catch-up cost. Do not reuse a shared credential store with competing refresh owners.
  • Record the owner decision for the concrete credential/storage/login changes before applying them.
  • In an isolated, owner-authorized live exercise, the phone and GUI keep their control identity while the CLI executes a turn under a different enrolled account. Label simulated limits separately from actual account execution.
  • The original local task remains open, the phone observes and replies to it, and local work continues without a fork or ownership transfer.
  • Switching execution accounts between turns preserves the remote connection and does not revoke unrelated sessions' network permissions; test reconnect and normal revocation separately.
  • The owner can tell which execution account served a turn and recover through the chosen supported setup.
  • Record upstream files changed and why each is needed. Escalate before broad patches to upstream files, as the remote milestone requires; record the estimated catch-up cost.

Relationships

Native child of #974 in Remote access on the fresh start. #975 is the completed route proof; this issue is the next work and natively blocks #976, which blocks #977. It is no longer blocked by #974.

Historical #951 is a bounded proxy experiment on stock 0.155.1, with a dated owner result. It demonstrated execution-account substitution outside the engine but left refresh ownership, supported transports and production setup unresolved. #381 records a retired Lab runtime's control/execution separation. Their old implementation and release gates are evidence, not prerequisites; neither proves this fresh deliverable.

Validation

Use focused tests for changed behavior and an isolated real iPhone/CLI account-switch exercise after authorization. Keep account identifiers, credentials and enrollment data private. Preserve the distinction between source behavior, historical evidence and installed live results.

Current source evidence: owner changes retire the remote relay. The same file also tests that refreshing credentials for the same owner preserves the relay.

Decisions

2026-09-26: the owner approved the exact #980 head in review 5325913144; #980 merged at e1ab370. Minimum account switching is part of the remote milestone. Remaining account needs and other-provider agents stay in the following milestone.

The first slice keeps phone/GUI control identity stable while allowing manual execution-account selection. Automatic rotation and the old Lab account pool are not prerequisites. Additional-credit purchases are excluded by the owner's value constraint. A future higher-capacity tier may prompt reassessment when it actually exists and meets the workload and value requirements.

2026-09-26 accepted proposal: use a loopback model router with fresh execution homes whose login, refresh and persistence are owned by stock Codex. Preserve the existing shared control server. Persist routing using an opt-in named provider; contain execution authentication failures as HTTP 403 so the control login is not refreshed. Prefer a native SSH Shortcut for phone selection. Concrete scope, review disposition and qualification evidence.

2026-09-26 owner decision in the active execution session: after discussing Tailscale reachability and the live-canary scope, the owner said, "and our harness may auto switch soon anyway! Ok, I love it if you do." This approves the proposed two fresh stock-managed execution homes/logins, opt-in provider entry, native SSH phone selector and disposable same-server qualification. Manual selection remains a fallback compatible with future harness automation; automatic rotation is not added to this slice. Existing tasks and the control login stay in place. The owner performs interactive sign-ins and the actual phone/cellular test. No protected-branch merge or release authorization is inferred.

2026-09-26 owner correction: all three owned accounts, including the phone/control identity, must be execution choices in one Shortcut. The owner completed fresh execution sign-ins for the two added labels. This supersedes the earlier control-identity exclusion while retaining independent stock-managed sign-ins, per-home refresh ownership and duplicate execution-identity rejection. No shared credential file or automatic rotation is introduced.

Open Questions

The owner has completed the three execution sign-ins and separately maintains the primary account's phone/control login. The owner explicitly corrected the prior assumption that this primary identity should be excluded from execution. Fresh stock-managed execution credentials permit all three accounts to be selected while the control sign-in stays fixed. Account addresses, device codes and private routing evidence stay out of public issues.

Real switching across the enrolled accounts, encrypted reasoning continuity and cross-account continuation after remote compaction have now passed. The owner has now used the expanded native phone menu and replied from the intended Remote task under its new execution choice. The router receipt, paired iOS activity and still-open local TUI independently confirm that result. Earlier native selector and cellular SSH proof also remain valid.

The original shared host retains its prior owner and active tasks. Prepare the concrete everyday-host transition before changing that owner or relay; the isolated pilot is not a blanket migration.

The owner reports reset allowance on all three accounts. Sustained depleted-control acceptance remains unproven, and no account should be deliberately depleted to manufacture it. Normal revocation/recovery also remains a separate live gate. Automatic rotation is outside this slice; the manual selector can support a future harness. Protected merge and release remain separate boundaries.

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

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions