TUI: Restore authentication after /logout

[moirahuang]

Description

Restores a complete authentication path after /logout in the headless TUI.

• Shows an explicit signed-out welcome state and starts device authorization only after user input.
• Starts fresh device authorization after local logout, then opens a validated /logout?continue=… browser URL so the prior web session is cleared first.
• Keeps the exact browser URL visible as a manual fallback and returns to the authenticated TUI without requiring a restart.
• Validates the device continuation as same-origin, exact-path, and CLI-sourced before passing it to the browser.

This is the client half of the auth-return handshake; the browser implementation is in warpdotdev/warp-server#13620.

Linked Issue

None.

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Manual end-to-end verification is documented below.

Testing

https://www.loom.com/share/2c6d09cb0d0c41658e5a97514f8f347b

• ./script/format --check
• ./script/check_no_inline_test_modules
• Presubmit workspace Clippy, default warp Clippy, and warp_completer Clippy with warnings denied
• cargo nextest run -p warp_tui (906/906 tests passed)
• Full terminal verification: signed-out welcome, unrelated input ignored, Enter starts device auth, wrapped logout continuation opens, browser completion returns to the authenticated TUI
• I have manually tested my changes locally with ./script/run

The changed surface is the headless TUI, so manual verification used the real TUI in a full terminal rather than the GUI ./script/run path.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Co-Authored-By: Oz oz-agent@warp.dev

[oz-for-oss]

@moirahuang

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[moirahuang]

• TUI: Restore authentication after /logout #14568 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[oz-for-oss]

Overview

This PR changes the TUI authentication flow so signed-out users see an explicit welcome screen, /logout starts a fresh device-authorization flow through the web logout endpoint, and the TUI renders new signed-out/waiting auth states with render-to-lines coverage. The logout continuation validation is appropriately constrained to the configured Warp web /device URL, and no approved spec context was available for a spec-alignment pass.

Concerns

• The signed-out welcome screen renders a static https://app.warp.dev/login fallback, but following that URL manually does not start the TUI device-code request or polling, so users who take the displayed fallback literally can remain stuck on the welcome screen.

Verdict

Found: 0 critical, 1 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

⚠️ [IMPORTANT] This static /login URL is rendered as the manual fallback, but opening it directly does not start AuthManager::authorize_device or the TUI polling flow; users who copy the displayed URL can log in on the web and still remain on SignedOutWelcome. Start device authorization before showing a manual URL and render the generated browser_url, or change the copy so it does not point users to a non-functional fallback.

[moirahuang]

going to update to not show this generic login URL but flagging that we won't be able to exactly match this mock anymore https://www.figma.com/design/yg5nbPZuGoAszHS3Rhvehu/TUI?node-id=1765-17599&m=dev

[kevinyang372]

This change makes sense to me

One UX improvement here we should do is when opening browser failed and user has to use the fallback url -- we currently only expose a manual click to open link action which could still fail if user is on a remote SSH machine. I think we should expose a copy url button (agent mode also suggests some other way like: provide an OSC-52 “copy URL” action or an OSC-8 hyperlink)

[moirahuang]

This change makes sense to me

One UX improvement here we should do is when opening browser failed and user has to use the fallback url -- we currently only expose a manual click to open link action which could still fail if user is on a remote SSH machine. I think we should expose a copy url button (agent mode also suggests some other way like: provide an OSC-52 “copy URL” action or an OSC-8 hyperlink)

​

added a c to copy URL action