You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 9, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 9, 2026. It is now read-only.
Prove the smallest iPhone route into an existing CLI session #975
Find the smallest working path from an iPhone to a session started in the normal local Codex CLI workflow. This must address the owner's 2026-09-25 meeting failure: three local sessions were unreachable from the phone and the owner simply waited.
gets and gives quick updates to a CLI session from away
This exact phrase from the merged DIRECTION.md admits the issue to Remote access on the fresh start.
Finish Line
A repeatable canary reaches one CLI-started session from the phone while the original local CLI remains open, reads its latest exchange, delivers one short reply into that same running session, and shows the acknowledgment in both views. Local input remains usable throughout; finishing or closing the local session to let the phone take over is not a pass. The issue records the route and limits, or the exact demonstrated gap and smallest proposed repair. A gap report completes this bounded investigation; it does not complete the remote-access milestone.
Current Status
State: complete as a bounded route investigation. The owner accepted the concurrent iPhone/CLI proof on 2026-09-26; the gaps below remain explicit follow-on work.
Next action: #976 makes the stock shared-CLI route repeatable and qualifies three-session use, busy/waiting behavior and phone reconnects. #977 then proves Launchplane/GitHub integration. Owner-approved #980 has since moved minimum account switching into the same remote milestone: #979 now precedes #976 and #977. This updates the follow-on routing; the original proof and its limits remain unchanged.
Blocked by: none for this investigation. Closing it does not claim the untested cases or the remote-access milestone passed.
Last verified: 2026-09-26. Owner phone Test → Test OK. appeared in the still-open CLI; LOCAL_AFTER_PHONE_975 then succeeded locally under the same thread ID. CLI/daemon 0.157.1; iPhone app 1.2026.258 on iOS 27.2. Zero upstream source changes. Enablement remains ephemeral, accounts match, and desktop remote hosting is off. The owner reports opening other local tasks, but full three-session delivery is untested.
Scope
Check stock behavior first, including whether a CLI-started session is visible, whether local and remote input can coexist, and whether returning to the CLI changes session identity. If stock behavior falls short, investigate the smallest catalog or sidecar route and name the exact missing capability before proposing an upstream patch.
Use the existing account arrangement. Do not change credentials, enrollment, account storage, or login flows without the direction-required owner decision. Preserve all active sessions.
Acceptance Criteria
Keep the original CLI and phone view open concurrently throughout read, reply and acknowledgment. Both observe the same conversation; attaching the phone must not require finishing, closing, restarting, forking or transferring ownership of the local session.
Record actual versions and distinguish installed capability from checked-in source and vendor documentation.
Test a session started from the CLI before phone attachment, not only a new task created from the phone.
Observe a read, one reply, same-session acknowledgment, and return to usable local CLI.
Follow-on qualification in Make three local CLI sessions readable and replyable from iPhone #976: record behavior during an active turn or a pending approval/question. The completed canary covers an idle task awaiting the next user message. These cases were not tested here and are not marked passed by closing this investigation.
Follow-on account work in Separate GUI and phone identity from CLI execution accounts on the fresh start #979: exercise stable phone/control identity with a different CLI execution account after the existing credential-change boundary is satisfied. Source inspection established that changing the server authentication owner disables its relay; no live account switch was performed. This remains unpassed and belongs to the next milestone.
Compare only routes needed to resolve the observed gap; recommend one with its setup cost, limitations, and upstream-file footprint. The shared CLI server owns remote hosting; desktop remote hosting must stay off for this shared registration. Upstream source files changed: zero.
Installed CLI and shared daemon: 0.157.1. Paired client inventory: iPhone, iOS 27.2, app 1.2026.258. A desktop client logged during diagnosis reported 26.917.71314; desktop remote hosting is not the passing route.
The disposable task was started in the CLI before phone attachment. Its local TUI remained open during the phone interaction.
Owner-observed phone exchange: Test → Test OK. The agent independently observed those exact messages in the still-open TUI and the same thread's stored turns. The phone turn completed at 11:11:54 UTC.
The agent then typed a local continuation into that TUI and received LOCAL_AFTER_PHONE_975 at 11:14:01 UTC. Same thread ID, no fork or writer transfer.
The remote pairing is claimed and connected; the managed daemon's PID and OS start time stayed unchanged throughout enabling and pairing. The owner reports that other locally open TUI sessions can also be opened from the phone; this is not yet a three-session delivery/reconnect pass.
Source footprint: zero upstream source changes. The selected route uses the existing shared CLI server and experimental remote-control RPCs. Enablement is currently ephemeral; durable startup and recovery remain work for Make three local CLI sessions readable and replyable from iPhone #976.
Limits: matching accounts only; desktop remote hosting must remain off for this shared registration. Busy-turn phone input, explicit approval/question waits, reconnection, three-session delivery and account-switch continuity are not claimed as passed.
Private evidence retains session identity, rendered terminal observations, process identity and API results. Public issue evidence omits account identifiers, device identifiers, enrollment data and pairing codes. Owner phone observations and agent host observations remain separately attributed. A mocked phone or an app-server RPC alone does not prove the phone experience.
Direction checkpoint, 2026-09-26: the owner stated, "Ok so we proved it works, now we need to figure out how to move forward and align with our direction." The successful route is accepted; no repeat of the completed pairing is required. The existing Finish Line permits closure with recorded gaps. Busy/waiting, durability and three-session qualification continue in #976; separate control/execution accounts continue in #979 under the later milestone. None of those follow-on results is claimed as passed here.
Read-only account assessment: same-owner refresh and owner-change tests distinguish a normal token refresh, which preserves the relay, from a different authentication owner, which disables it. This is checked-in source evidence, not a live account-switch test on 0.157.1.
Decisions
Use the existing shared CLI server as the remote host. The owner-approved stock route passed an actual iPhone read/reply plus continued local input while the original TUI remained open. No upstream source files were changed and no new application or adapter is currently needed for this matching-account idle case.
The desktop app's remote hosting must remain off for this shared registration. Its earlier phone route attempted to resume the CLI task under a different server and hit the active-writer lock. Enabling both remote hosts produced HTTP 409, Remote app server already online. Turning off desktop remote hosting released the relay so the CLI's existing server could connect without a restart. Deleting phone pairings alone did not release it.
The owner explicitly requires concurrent local and phone access. Closing, finishing, restarting or forking the local task to permit phone takeover is not an acceptable substitute. The historical Every Code/Discord-Blue workflow supplies that behavioral requirement, not a requirement to revive the retired implementation.
The current pass uses aligned phone/CLI accounts and ephemeral remote enablement. The official Remote guide requires matching account/workspace for its supported desktop flow. Separate working-account continuity, active-turn phone behavior and durable startup are not proven by this canary. A stable phone/control identity remains the desired end state; no account changes or credential rewrites are authorized by the canary result alone.
Separate incident evidence: before the approved remote-enable test, four threads failed together with revoked application network permission, preceded by account-mismatch and token_revoked events. Upstream policy behavior explains how account/requirements changes can cancel existing requests. The exact triggering action remains unproven. The earlier local-only test did not change credentials, enrollment, network policy or daemon lifecycle. Later remote enablement and pairing were separately approved and are recorded as such.
2026-09-26 plan alignment: keep the successful stock route and the current DIRECTION.md milestone order. Complete this bounded investigation with its known gaps. Busy/waiting qualification moves to the already planned #976; account independence moves to #979 under Other needs on the fresh start. No direction-file change, new runtime or source patch is selected.
Open Questions
The route question is resolved: an already-running CLI task can be used from the iPhone while its original TUI stays open when both clients use the same shared CLI server.
#976 owns remaining busy/waiting, durable setup, three-session and reconnect qualification. #979 owns stable control identity across execution-account changes. Preserve the currently working sessions and enrollment while those issues proceed in DIRECTION.md order.
Completed the bounded route investigation with the owner's accepted stock iPhone/CLI proof and explicit follow-on limits.
The iPhone sent Test and received Test OK. in a CLI-started task while its original TUI stayed open; a subsequent local turn succeeded in that same task. Stock CLI/daemon 0.157.1, zero upstream source changes. The existing shared CLI server hosts Remote; desktop remote hosting is off for the shared registration.
The currently working setup is ephemeral and uses matching accounts. Three-session delivery, durable setup/recovery, active-turn/waiting behavior and phone reconnects are not marked passed: #976 owns that qualification. #977 then proves Launchplane/GitHub integration. Stable phone/GUI control identity with separate CLI execution accounts is #979 in Other needs on the fresh start, after #974, preserving DIRECTION.md's milestone order.
The account assessment is source-based: a changed authentication owner disables the relay; a same-owner token refresh preserves it. No live account switch or credential change was performed for that assessment.
Full-history unanswered-comment scan found no external comments or attention items and no coverage errors. Closing this investigation does not close the parent or milestone and does not authorize login changes. The current runtime and enrollment were left unchanged during this planning turn.
Objective
Find the smallest working path from an iPhone to a session started in the normal local Codex CLI workflow. This must address the owner's 2026-09-25 meeting failure: three local sessions were unreachable from the phone and the owner simply waited.
This exact phrase from the merged DIRECTION.md admits the issue to
Remote access on the fresh start.Finish Line
A repeatable canary reaches one CLI-started session from the phone while the original local CLI remains open, reads its latest exchange, delivers one short reply into that same running session, and shows the acknowledgment in both views. Local input remains usable throughout; finishing or closing the local session to let the phone take over is not a pass. The issue records the route and limits, or the exact demonstrated gap and smallest proposed repair. A gap report completes this bounded investigation; it does not complete the remote-access milestone.
Current Status
State: complete as a bounded route investigation. The owner accepted the concurrent iPhone/CLI proof on 2026-09-26; the gaps below remain explicit follow-on work.
Next action: #976 makes the stock shared-CLI route repeatable and qualifies three-session use, busy/waiting behavior and phone reconnects. #977 then proves Launchplane/GitHub integration. Owner-approved #980 has since moved minimum account switching into the same remote milestone: #979 now precedes #976 and #977. This updates the follow-on routing; the original proof and its limits remain unchanged.
Blocked by: none for this investigation. Closing it does not claim the untested cases or the remote-access milestone passed.
Last verified: 2026-09-26. Owner phone Test → Test OK. appeared in the still-open CLI; LOCAL_AFTER_PHONE_975 then succeeded locally under the same thread ID. CLI/daemon 0.157.1; iPhone app 1.2026.258 on iOS 27.2. Zero upstream source changes. Enablement remains ephemeral, accounts match, and desktop remote hosting is off. The owner reports opening other local tasks, but full three-session delivery is untested.
Scope
Check stock behavior first, including whether a CLI-started session is visible, whether local and remote input can coexist, and whether returning to the CLI changes session identity. If stock behavior falls short, investigate the smallest catalog or sidecar route and name the exact missing capability before proposing an upstream patch.
Use the existing account arrangement. Do not change credentials, enrollment, account storage, or login flows without the direction-required owner decision. Preserve all active sessions.
Acceptance Criteria
Relationships
Native child of #974 and blocker of #976.
Historical evidence: #381, #385, #388. Their retired runtime and account architecture are not prerequisites.
Official source: https://learn.chatgpt.com/docs/remote-connections . Checked-in capability evidence: codex-rs/cli/src/main.rs at 1886fac.
Validation
2026-09-26 live evidence:
Private evidence retains session identity, rendered terminal observations, process identity and API results. Public issue evidence omits account identifiers, device identifiers, enrollment data and pairing codes. Owner phone observations and agent host observations remain separately attributed. A mocked phone or an app-server RPC alone does not prove the phone experience.
Direction checkpoint, 2026-09-26: the owner stated, "Ok so we proved it works, now we need to figure out how to move forward and align with our direction." The successful route is accepted; no repeat of the completed pairing is required. The existing Finish Line permits closure with recorded gaps. Busy/waiting, durability and three-session qualification continue in #976; separate control/execution accounts continue in #979 under the later milestone. None of those follow-on results is claimed as passed here.
Read-only account assessment: same-owner refresh and owner-change tests distinguish a normal token refresh, which preserves the relay, from a different authentication owner, which disables it. This is checked-in source evidence, not a live account-switch test on 0.157.1.
Decisions
Use the existing shared CLI server as the remote host. The owner-approved stock route passed an actual iPhone read/reply plus continued local input while the original TUI remained open. No upstream source files were changed and no new application or adapter is currently needed for this matching-account idle case.
The desktop app's remote hosting must remain off for this shared registration. Its earlier phone route attempted to resume the CLI task under a different server and hit the active-writer lock. Enabling both remote hosts produced HTTP 409, Remote app server already online. Turning off desktop remote hosting released the relay so the CLI's existing server could connect without a restart. Deleting phone pairings alone did not release it.
Keep the single-writer boundary and share that running owner between clients. Source evidence at baseline 2deb542: cross-process writer exclusion and resuming a thread already running in its owning server.
The owner explicitly requires concurrent local and phone access. Closing, finishing, restarting or forking the local task to permit phone takeover is not an acceptable substitute. The historical Every Code/Discord-Blue workflow supplies that behavioral requirement, not a requirement to revive the retired implementation.
The current pass uses aligned phone/CLI accounts and ephemeral remote enablement. The official Remote guide requires matching account/workspace for its supported desktop flow. Separate working-account continuity, active-turn phone behavior and durable startup are not proven by this canary. A stable phone/control identity remains the desired end state; no account changes or credential rewrites are authorized by the canary result alone.
Separate incident evidence: before the approved remote-enable test, four threads failed together with revoked application network permission, preceded by account-mismatch and token_revoked events. Upstream policy behavior explains how account/requirements changes can cancel existing requests. The exact triggering action remains unproven. The earlier local-only test did not change credentials, enrollment, network policy or daemon lifecycle. Later remote enablement and pairing were separately approved and are recorded as such.
2026-09-26 plan alignment: keep the successful stock route and the current DIRECTION.md milestone order. Complete this bounded investigation with its known gaps. Busy/waiting qualification moves to the already planned #976; account independence moves to #979 under Other needs on the fresh start. No direction-file change, new runtime or source patch is selected.
Open Questions
The route question is resolved: an already-running CLI task can be used from the iPhone while its original TUI stays open when both clients use the same shared CLI server.
#976 owns remaining busy/waiting, durable setup, three-session and reconnect qualification. #979 owns stable control identity across execution-account changes. Preserve the currently working sessions and enrollment while those issues proceed in DIRECTION.md order.