[APP-5097] Defer startup API key validation - #14711
Conversation
Co-Authored-By: Warp Agent <agent@warp.dev>
| entrypoint: TuiEntryPoint::CliCommand { .. }, | ||
| } => true, | ||
| fn auth_initialization(&self) -> AuthInitialization { | ||
| match self.api_key() { |
There was a problem hiding this comment.
basically making no eager installation anymore
| (user_is_logged_in && !matches!(launch_mode, LaunchMode::CommandLine { .. })) | ||
| .then_some(StartupUserAuthentication::RefreshUser) | ||
| }); | ||
| let startup_authentication = if matches!(launch_mode, LaunchMode::CommandLine { .. }) { |
There was a problem hiding this comment.
can simplify the logic here too
|
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 Powered by Oz |
There was a problem hiding this comment.
Overview
This PR defers explicit startup API keys out of shared AuthState until server validation succeeds, and updates GUI, TUI, and CLI startup auth paths to promote validated credentials later. I reviewed the attached diff, PR description, and spec context; no approved repository spec context was available.
Concerns
- This changes user-visible GUI/TUI startup and CLI authentication behavior, but the PR description does not include screenshots or a screen recording demonstrating the new successful and failed API-key flows end to end. Per the repository review guidance, user-facing behavior changes need visual evidence attached before merge.
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

Description
Explicit startup API keys were installed into shared
AuthStatebefore the server validated them. Credential presence made GUI and TUI startup appear authenticated and allowed unrelated clients to retrieve an unvalidated key.This change makes GUI, interactive TUI, and Oz CLI hold explicit startup API keys outside shared auth state until
fetch_usersucceeds. GUI and TUI share the deferred startup-auth path, while Oz CLI keeps its separate IAP-gated command lifecycle and validates the pending key before dispatch. The obsolete eager API-key initializer has been removed so failed validation leaves the process fully logged out.PR with more context: #14620
Linked Issue
APP-5097
Testing
./script/formatcargo nextestselection covering launch-mode policy, CLI authentication-source selection, failed pending-key validation, and successful key promotion: 10 passedcargo clippy -p warp --lib --tests -- -D warningsgit diff --check./script/runAgent Mode
CHANGELOG-NONE
Co-Authored-By: Warp Agent agent@warp.dev