[habdelra]

Linear: CS-14314

The secure origin is the separate origin (secure.boxel.ai, https://localhost:4208/secure in development) where Boxel signs people in, so that card code running in the app can never read a typed password. Its page is one shell document with several modes, picked by the mode query parameter. Two of those modes sign in for the Boxel CLI instead of for the app:

• cli-sign-in is what boxel keys sign-in opens. Once signed in, the window hands the CLI a secure session, which is the only session that can change the user's keys. The CLI uses it for boxel keys and nothing else.
• cli-auth is what boxel profile add opens. Once signed in, the window hands the CLI a single-use Matrix login token, which the CLI swaps for a Matrix device of its own (its access to the user's workspaces). The CLI's link always carries session=secure, so the window hands it the secure session in the same step too. A new profile can therefore manage keys without a separate boxel keys sign-in. A cli-auth link without session=secure gets the login token alone. That's the link a CLI that can't hold a secure session reaches, by way of the app's /cli-auth page.

Both modes draw the same SignInScreen component the app's own sign-in uses. That screen takes an @title and an intro block so a page that signs in for something other than the app can say so. The intro takes the place of the line inviting a new user to start with Google.

Before this PR, neither page said fully what the user was agreeing to:

• cli-sign-in passed neither. Someone running boxel keys sign-in landed on "Sign in to your Boxel Account", under a subtitle offering to create an account with Google. Nothing said they were signing in their terminal, or what that sign-in would let it do.
• cli-auth was titled "Authorize Boxel CLI", but its intro mentioned only access to the user's workspaces. It said nothing about keys, even though the CLI walks away with a session that can manage them.

This PR fixes both:

• cli-sign-in passes SignInForm (which forwards both to SignInScreen) the title "Authorize Boxel CLI" and the intro "Signing in lets the Boxel CLI running on this computer manage your keys." The title matches the profile sign-in, since in both cases the user is authorizing the CLI. The intro's paragraph sets margin: 0 in a scoped style, as cli-auth's does, because the screen's .intro wrapper already sets the spacing around it.
• cli-auth names keys whenever the link asks for the secure session (callback.profile.secureSession, which the page already reads to decide what to hand over). Signed out, it reads "Signing in gives the Boxel CLI running on this computer access to your workspaces, and lets it manage your keys." When the window is already signed in, it asks that account to confirm its password: "…access to the workspaces of @user:server, and to let it manage their keys." A link without session=secure keeps the workspaces-only copy, because that's all it hands over.

Nothing else changes: the fields, Google button, links and hand-off to the CLI's loopback listener stay the same.

build-record.json is regenerated. The secure-origin build checks that every module it bundles is recorded, and the cli-sign-in page now has its own scoped CSS file.

Screenshots

Both pages are rendered from this package's build, origin/main for before and this branch for after, against the development stack's realm server, with Google offered so the subtitle the cli-sign-in intro replaces is visible.

cli-sign-in (boxel keys sign-in)

Before	After

cli-auth (boxel profile add, whose link carries session=secure)

Before	After

Tests

These are component tests in packages/secure-origin/tests/integration/sign-in-test.gts:

• cli-sign-in: a new test renders the page with Google offered. It checks that the page is titled "Authorize Boxel CLI", that it shows the keys intro, and that the Google subtitle is gone.
• cli-auth, link with session=secure: the existing intro assertion now expects the keys clause. The signed-in test now also asserts the full confirm-your-password line, keys included.
• cli-auth, link without session=secure: two new tests check that the intro and the confirm line both keep the workspaces-only copy.

pnpm lint and pnpm test (unit and component) pass in packages/secure-origin. None of the Playwright specs assert either page's intro, or cli-sign-in's heading on a valid link, so they don't move.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-24T20:13:31.893848Z	9043006	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[habdelra]

[Claude Code 🤖] This review traced what the CLI receives from each secure-origin CLI sign-in mode and checked the new copy and the PR description against that. It also checked the test, the build record (lint:build in check mode), and the Playwright specs that open these modes. It did not look at visual design beyond the screenshots.

No blocking issues. The new title and intro are right for cli-sign-in, and the test fails without the change. The PR description misstates what cli-auth hands over, and that wrong statement is what the new intro's wording is contrasted against.

1. The description says cli-auth grants less than it does (description accuracy, non-blocking; the cli-auth copy is a pre-existing follow-up). The description says cli-auth gives the CLI a single-use login token, and that the new intro "names what this particular sign-in grants", as opposed to the profile sign-in. But buildSecureCliAuthUrl in packages/boxel-cli/src/lib/sso-login.ts always adds session=secure, so handProfileSignIn in packages/secure-origin/src/security/cli-handoff.js gives boxel profile add the same seven-day secure session that boxel keys sign-in gets, along with the login token. profile add then saves it as the profile's keys session and prints "Signed in to manage keys". So cli-auth grants keys management too, yet its intro ("…access to your workspaces") doesn't say so. Please correct the description. Separately, decide whether cli-auth's intro should also mention keys: this PR argues that a CLI sign-in page should say what it lets the CLI do, and cli-auth is the page where that is still untrue. That copy fix can be a follow-up, not this PR.

Red checks: none. A few checks are still running.

[habdelra]

[Claude Code 🤖] On the review's finding that cli-auth grants more than its copy and the description said: fixed in 3f43bc24ca, and the description is rewritten.

boxel profile add's link always carries session=secure, so the profile sign-in also hands the CLI the secure session. The cli-auth page now names keys whenever callback.profile.secureSession is set. That covers the signed-out intro ("…access to your workspaces, and lets it manage your keys.") and the confirm-your-password line ("…access to the workspaces of , and to let it manage their keys."). A link without session=secure hands over only the login token, so it keeps the workspaces-only copy. Component tests cover both links and both variants of the intro, and the description has a fresh before/after of cli-auth.

[github-actions]

Host Test Results

    1 files  ±    0      1 suites  ±0   1h 38m 39s ⏱️ + 1h 31m 48s
5 936 tests +5 360  5 925 ✅ +5 349  11 💤 +11  0 ❌ ±0 
5 951 runs  +5 375  5 940 ✅ +5 364  11 💤 +11  0 ❌ ±0 

Results for commit 229c746. ± Comparison against earlier commit 91c8f0b.

Realm Server Test Results

    1 files  ± 0    366 suites  +1   2h 10m 13s ⏱️ + 7m 35s
6 105 tests +37  6 105 ✅ +37  0 💤 ±0  0 ❌ ±0 
6 168 runs  +37  6 168 ✅ +37  0 💤 ±0  0 ❌ ±0 

Results for commit 229c746. ± Comparison against earlier commit 91c8f0b.