feat: add Kiro reauthentication action - #2980
Conversation
Previously the only way to change claudeOAuthKeychainPromptMode away from onlyOnUserAction was a defaults write — users hitting "background repair is suppressed... Click Refresh" had no in-app way to opt into always-on background repair. Adds a Privacy-section toggle in Advanced settings wrapping the existing mode as a simple on/off (always vs onlyOnUserAction), leaving the never/prompt-free path untouched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HzWPve8BJ9KqMcSBiGXzPN
Codex had no settings action to recover from an expired OAuth token
short of running \`codex login\` manually in a terminal. Adds a
settingsActions entry (same pattern already used by Antigravity's
"Login with Google" button) that calls the existing runLoginFlow ->
CodexLoginRunner -> \`codex login\` subprocess path.
Antigravity already exposes an equivalent button ("Login with Google" /
"Add Google Account" in Settings > Antigravity > Connection) wired to a
real browser OAuth flow via AntigravityLoginRunner — no change needed
there. Kiro has no CLI login/auth surface in its \`kiro\` binary
(confirmed via \`kiro --help\`: file/diff/chat/tunnel commands only, no
login or auth subcommand), so no button was added for it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HzWPve8BJ9KqMcSBiGXzPN
Earlier claim that Kiro has no CLI login was wrong — it was tested against \`kiro\` (the editor launcher), not \`kiro-cli\` (a separate binary at ~/.local/bin/kiro-cli). \`kiro-cli login\` opens a real browser OAuth flow and blocks until it completes, same shape as \`codex login\`. Adds BinaryLocator.resolveKiroCLIBinary (mirrors resolveAntigravityBinary) and KiroLoginRunner (mirrors CodexLoginRunner's subprocess-lifecycle handling) to wire a settingsActions "Re-authenticate" button through the existing runLoginFlow -> StatusItemController path already used by Codex and Antigravity. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HzWPve8BJ9KqMcSBiGXzPN
Addresses clawsweeper P2 finding on #2340: KiroLoginRunner only returned its captured output once the kiro-cli subprocess exited, but a device-flow login prints its URL and one-time code while still polling for browser approval, so the Settings action never showed it before the 120s timeout killed the login. Adds a live poll of the still-running subprocess's pipes for a device-flow URL and surfaces it as soon as it appears via an onProgress callback, instead of waiting for process completion.
Addresses clawsweeper P2 finding on #2340: KiroProviderImplementation returned true unconditionally, so the shared login contract refreshed usage even after a missing CLI, timeout, failed login, or cancellation. runKiroLoginFlow now returns the actual outcome.
Mirrors CodexLoginRunnerTests' process-lifecycle coverage for the new subprocess runner, which previously shipped with no test changes.
The Advanced pane's Boolean toggle wrote the same claudeOAuthKeychainPromptMode preference as the existing three-mode picker in Provider settings, but couldn't represent "Never prompt" - two controls, conflicting semantics. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018gG6Sz5aaJw2vbT2DSgtJU
Co-authored-by: Vit129 <vitosk129@gmail.com>
|
🦞👀 Pull request received. I will update this pull request when review starts. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6352ab7694
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| { | ||
| self.resolveBinary( | ||
| name: "kiro-cli", | ||
| overrideKey: "KIRO_CLI_PATH", |
There was a problem hiding this comment.
Use the Kiro binary override during usage refresh
When KIRO_CLI_PATH points to a binary outside the effective PATH, this resolver lets reauthentication succeed, but the post-login refresh still constructs KiroStatusProbe, whose resolver is TTYCommandRunner.which("kiro-cli"); the Kiro descriptor is named kiro and does not register this binary locator, so which cannot see the override and the successful login is immediately followed by a CLI-unavailable refresh. Wire the same locator into the Kiro provider/probe, or ensure the override is added to the refresh environment.
Useful? React with 👍 / 👎.
| } | ||
| } | ||
|
|
||
| let timedOut = await self.wait(timeout: timeout, termination: termination) |
There was a problem hiding this comment.
Terminate the login subprocess when its task is cancelled
If CodexBar shuts down while Kiro login is polling, cancelShutdownTasks() cancels loginTask, but this continuation wait never observes task cancellation and only calls terminate after the 120-second timeout. Since application termination destroys that timeout task as well, the independently launched kiro-cli process group can remain orphaned after CodexBar exits; make cancellation resolve the wait and run the existing process-group teardown.
Useful? React with 👍 / 👎.
|
Codex review: needs changes before merge. Reviewed August 16, 2026, 11:09 AM ET / 15:09 UTC. ClawSweeper reviewWhat this changesAdds an explicit Kiro Settings/menu re-authentication action that runs Merge readiness⛔ Blocked by patch quality or review findings - 6 items remain Keep open: both prior P2 blockers remain on the supplied latest head—an override-selected Kiro CLI cannot refresh usage, and cancelling the login task does not terminate its subprocess. Likely related people: steipete (medium confidence). Priority: P2 Review scores
Verification
How this fits togetherCodexBar’s Kiro provider locates flowchart LR
A[Settings or menu action] --> B[Kiro login flow]
B --> C[Resolve Kiro CLI]
C --> D[Browser device login]
D --> E[Login result]
E --> F[Provider usage refresh]
F --> G[Menu and Settings usage]
Before merge
Findings
Agent review detailsSecurityNone. Review metricsNone. Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Copy recommended automerge instructionTechnical reviewBest possible solution: Use one provider-scoped Kiro CLI resolver for login, availability, version detection, and status probing, and make the login wait cancellation-aware so teardown always reaches the process group. Do we have a high-confidence way to reproduce the issue? Yes, from source: set Is this the best way to solve the issue? Yes for the repair direction: sharing the Kiro resolver across login and probing, then tying cancellation to the existing process-group teardown, preserves the intended explicit user action without adding parallel behavior. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f0824413c72a. LabelsLabel justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
Summary
kiro-cli login, with bounded process teardown, device-flow progress, failure presentation, and refresh only after success.Auth and Keychain review
neverintoalways. The existing policy defaults toonlyOnUserAction; background delegated refresh crosses the opaque CLI/Keychain boundary only for stored modealways;neverremains fail-closed. This branch adds no Claude background-prompt path.ProcessPipeCapture.currentSnapshot()is a synchronized additive read, andresolveKiroCLIBinaryis a provider-specific additive resolver. Existing process/path suites pass. New UI and alert strings contain only Kiro data; no cross-provider identity fields are used.No live Keychain access or real login flow was executed.
Verification
make checkCODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --skip-build --no-parallel --filter 'KiroLogin|CodexLogin|ClaudeOAuth|Keychain'— 360 macOS tests and 5 Linux tests passedCODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --skip-build --no-parallel --filter 'KiroBinaryLocator|PathBuilder|SubprocessRunner|ProviderSettingsDescriptor|ProviderArchitectureGatekeeper|SettingsStoreCoverage|CodexAccountsSettingsSection'— 203 tests passedThanks @Vit129 for the original implementation and follow-up fixes in #2340.