fix(codex): the pane re-authenticates itself when the token is dead

[defangdevs]

Closes the first item of #187.

The dead end

On a box whose ChatGPT token had been invalidated, the codex Remote Control pane showed this and could not get out of it:

  ✗ Could not mint a pairing code:
Error: remoteControl/pairing/start failed: ... HTTP 401 Unauthorized, cf-ray: ...,
body: {"error":{"message":"Your authentication token has been invalidated. Please try
signing in again.","code":"token_invalidated"},"status":401}
    Press Enter to try again.

codex login status is a local check — it reports how ~/.codex/auth.json was minted, not whether the backend still honours it — so it kept saying "Logged in using ChatGPT", device_login kept correctly declining (it deletes auth.json as it starts, so the guard has to stay), and pairing was the only thing that noticed. Enter re-ran exactly that. The single escape was typing login, a word the pane's footer mentions but nothing explains.

The change

pair() now classifies its failure and onboard() acts on it:

failure	before	after
token invalidated / 401	3 attempts, raw JSON-RPC blob, "Press Enter" (forever)	fails once, prints the server's own message, drops the credentials and re-runs the device flow — no keystroke
fresh sign-in still rejected	—	says so once, points at login and at account access; no logout/device-auth spin
enrollment race, no network	3 attempts, raw error, "Press Enter"	unchanged, and never drops working credentials

The automatic retry is behind a flag rather than unconditional (logout is destructive), and the flag clears on a successful pairing, so a token that expires hours into a pane's life still gets one automatic recovery. login stays a typed word because the wrong-account case produces no error string to detect — only the user knows.

Two things worth calling out:

• No grep. The agent unit's PATH carries coreutils but no gnugrep, so grep: command not found would have read as "not an auth failure" and silently restored the dead end. Matching is shell globs; the reason string is extracted with parameter expansion.
• relogin() clears was_signed_in when the box ends up signed out (a device flow the user walked away from), so the health loop still notices sign-in whenever it completes. The transition check keeps its short-circuit — a signed-in pane spawns no login status every 5s.

Testing

tests/sessions.nix drives the supervisor wrapper directly against a stub codex (a real server-side rejection is not producible in the sandbox, and daemon version fails in the stub so the health loop ends) and asserts all three rows of that table, including call counts: one failed pair then one that succeeds for the recovering case, exactly one logout for the hopeless case, three pairs and zero logouts for the network case.

Verified locally on this aarch64 box by extracting the generated wrapper and running the same four scenarios (plus logged-out, unchanged) under a PATH containing only coreutils — proof the grep-free matching works:

stale:     pair=2 logout=1 paired=1 http401_on_screen=0 press_enter=0
persist:   logout=1 devauth=1 still_rejects=1
offline:   pair=3 logout=0 press_enter=1
loggedout: devauth=1 paired=1

module-generated-up-to-date, multi-user and module-single-file pass natively; the sessions VM test is x86_64-only, so CI runs it.

Not in scope: the remotable-vs-"local" codex question in #187, which is a distinct change (the CLI and the settings form both hardcode remoteControl: true) and is waiting on a clarification in the issue.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FY7YhQDw21A83rdQtkmtAi