Signing in from the coder is two logins wearing one name #129
- AtlantisPleb opened this issue 6d ago
-
A Author 5d ago CLAIM
actor/session: codex-cli-backlog-2026-08-26
base: openagents 4ea97c0bca; openagents.com b259fde51b
worktrees: openagents-cli-backlog; openagents.com main
scope: Complete the device sign-in contract by attaching a bounded computer name to the authorization and displaying it with the approved scopes. Preserve the landed return-to-device flow and OpenAgents wording.
paths: crates/openagents-cli/src/auth.rs and tests; openagents.com device authorization context, schema, migration, controller, LiveView, and tests
hot contracts: anonymous device authorization API; authenticated approval page; CLI credential bootstrap
verification: Rust auth/unit/check suites; focused Phoenix context/controller/LiveView/return tests; mix precommit for openagents.com
claimed_at: 2026-08-27T00:54:00Z -
A Author 5d ago Completed the device sign-in contract.\n\n- sends a bounded, control-character-free computer name from the CLI without changing requested scopes.\n- stores the display-only name and shows it beside the server-owned permissions on the approval page.\n- Existing clients remain compatible and appear as an unnamed computer.\n- Verification passed: 922 CLI library tests, 27 CLI auth integration tests, the CLI all-target compile check, and all 5,126 Phoenix precommit checks.
- closed this as completed 5d ago
-
A Author 5d ago Correction: CLI commit 06e64ca6d1 sends the bounded computer name. Phoenix commit 139debc stores and displays it beside server-owned scopes. The verification totals in the preceding completion comment are accurate.
The session says "Press Enter to log in with GitHub." and then opens
https://openagents.com/device. GitHub is an implementation detail of howOpenAgents authenticates; the reader is logging in to OpenAgents. The message
should say so.
That is the small half. The real problem is that it is two logins.
What actually happens
/deviceis a LiveView insidelive_session :authenticated(
router.ex:244), so it requires a signed-in browser session of its own. Areader who is not signed in to openagents.com is bounced through that login
first, and only then reaches the device page — where they are asked to approve
a second thing, which does not visibly relate to the sign-in they just
completed. Two sign-ins, one intent, and nothing on screen connecting them.
Once approved, the code they were given by the terminal still has to be
matched. It works, but it reads as a coincidence rather than a flow.
What to build
One flow from the reader's side:
/device?user_code=…already prefills — thatpart works and is why device approvals succeed in seconds where the
Computers page's, which ignores its params, expire unapproved; see #112).
return them to the device page with the code still in hand, so approving
is the next click and not a fresh errand. That return path is the actual
work here.
approving is an informed act rather than a reflex.
Why it is worth doing properly
This is the first thing a new user does. It currently costs two logins, a code
transcription in the worst case, and a moment of "did that work?" — and the
terminal gives no sign of progress until
--resumeis run. A single flow thatends with the session already authenticated is the difference between a product
and a procedure.
Related: #128 (there is no way to log out), #112 (the same prefill problem,
solved, on the Computers page).