You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(kiro): slow kiro-cli starts no longer show Kiro as unavailable - #29841
Kiro's status check gives kiro-cli --version 4 seconds. A healthy CLI that starts slowly loses that race. Common causes are a cold start, a shim, a version manager, or antivirus scanning. When it loses, the check reports an error, "Failed to run kiro-cli --version.", with no version, and Kiro shows as Unavailable until a later check happens to answer within 4 seconds.
#28400 fixed this for Grok, Pi and fx by giving --version 10 seconds. Kiro's check uses the same probe pattern but still has the shared 4 second default.
Change
Kiro gets the same local VERSION_PROBE_TIMEOUT_MS = 10_000 that Grok, Pi and fx use, and only kiro-cli --version uses it. The whoami, model-list and agent probes already allow 10 seconds and do not change. The message text does not change. A CLI that really hangs still times out, now after 10 seconds.
Scope and approval
Very small, focused fix for an obvious bug, so no prior issue: this applies the change accepted in #28400 to the one sibling status check that #28400 did not reach. It is a 4 line change in one file plus a test.
Overlap search: the local PR index and GitHub search for Kiro, version and timeout found no PR about this. #24676 (open) does the same for Muse and touches only provider-muse. #28400 covered Grok, Pi and fx only.
--version answers after 6 seconds: on main this fails with AssertionError: expected 'error' to equal 'ready'. With the fix the snapshot is ready, with version 2.27.0.
--version never answers: the existing "Failed to run kiro-cli --version." result still comes back.
vp test run src/provider/KiroProvider.test.ts: 12 passed.
vp run check:changed: passed (format, lint, knip, typecheck of 10 packages, tests 13/13).
Runtime check: I ran the real checkKiroProviderStatus with real child processes against a fake kiro-cli that sleeps 6 seconds before printing its version and reports signed out:
main: 4.0s error null Failed to run `kiro-cli --version`.
fixed: 6.4s error 2.27.0 Kiro CLI is installed but not signed in. Run `kiro-cli login`.
Not checked: a real slow Kiro install, and captures in a client. The status text is the same text the existing error path already shows.
Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.
Created with Claude Opus 5.5 in Claude Code (T3 Code).
Macroscope's review found this PR requires human approval — Kiro's version check now waits up to 10 seconds instead of 4, accommodating slow startups while delaying failure reporting for hung processes. This built-in timeout change requires human review of the responsiveness tradeoff.
You can add or adjust custom eligibility rules. Learn more.
Reviewing files that changed from the base of the PR and between 2ed92cd and b0c446f.
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
Trigger review
No actionable comments were generated in the recent review.
Walkthrough
The Kiro CLI version probe now has a dedicated 10-second timeout. Tests cover a delayed version response and a command that does not respond before the timeout.
Changes: Kiro version probe
Layer / File(s)
Summary
Set and test the version probe timeout packages/provider-kiro/src/server/status.ts, apps/server/src/provider/KiroProvider.test.ts
The version probe uses a 10-second timeout instead of the shared default. Tests verify that a 6-second delay returns version 2.27.0, while a nonresponsive probe times out with an error, a null version, and the version-probe failure message.
Slow Kiro startup has more time to complete; no actionable merge-blocking risk was found.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly and concisely identifies the Kiro-specific fix for slow CLI startup detection. It matches the main change and uses a conventional commit format.
Description check
The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the failure, the 10-second timeout change, the focused scope, test results, runtime va…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Description check
Explanation
The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the failure, the 10-second timeout change, the focused scope, test results, runtime validation, and remaining limitations.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
Reviewing files that changed from the base of the PR and between 30b9c4a and 2ed92cd.
Files selected for processing: 2
apps/server/src/provider/KiroProvider.test.ts
packages/provider-kiro/src/server/status.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.
Merged current main without conflicts to pick up its fix for the unrelated check-changed.test.ts Astro lint expectation that failed CI. The PR remains two files with the original Kiro timeout change intact.
Blacksmith verification passed: vp run check:changed 61c3794c32b0eeebfac09add43e403618c65d2d7 (format, lint, knip, GraphQL, 10-package typecheck, focused tests), plus all 27 tests in KiroProvider.test.ts and check-changed.test.ts. Two independent code reviews found no blockers at b0c446fc8550795860866cbbfc57cc8bd07c66ab.
Live Kiro/client behavior remains unverified because kiro-cli is not installed on this VM. Macroscope's human approval of the timeout tradeoff remains for Maria.
Partial verification at b0c446fc8550795860866cbbfc57cc8bd07c66ab, using separate main and PR checkouts, vp i, one background dev server at a time, and repository Playwright with /usr/bin/google-chrome. No code changes or mocked provider output.
Installed real Linux kiro-cli 2.37.1. On both main (61c3794c32) and the PR, added Kiro through settings → providers. Both detected its version and showed the expected signed-out message.
On the PR, a nonexistent binary path showed "Not found". Restoring the default path recovered version 2.37.1 and the signed-out message. Refresh also preserved the correct result. The recording shows this neighboring behavior, not the slow-start fix.
Added the real repository as a project through the app, selected Codex gpt-6.1-sol, and completed a real turn through the local proxy. The client displayed PROVIDER_PATH_OK.
Not verified
The changed 4-to-10-second timeout is unverified. The real CLI answers in 0.02–0.4 seconds here, so main did not reproduce the original slow-start failure. I did not substitute a delayed fake CLI or shim. This is not evidence that the slow-start fix works.
A genuinely hung version probe, authenticated Kiro turns, Kiro model/agent discovery, native desktop/mobile clients, and macOS/Windows behavior were not exercised. Kiro has no signed-in account on this VM. Existing CI is green; no new checks were run and no fix was pushed.
Thanks. That matches what we'd expect: a kiro-cli that answers in under half a second can't show the difference. This PR gives Kiro's --version probe the same 10-second limit that #28400 gave Grok, Pi and fx for slow-starting CLIs (cold start, a version-manager shim, antivirus scanning). Kiro was the remaining driver on the shared 4-second default. The adapter test covers the boundary itself: a version probe that answers after the old limit fails on main and passes here. If you'd like a live run as well, a wrapper that sleeps about 6 seconds before running kiro-cli --version, set as Kiro's binary path, reproduces the slow-shim case. Main shows Kiro as Unavailable, and this head shows its version. The verifier lane can capture that if it helps.
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:XS0-9 changed lines (additions + deletions).vouch:trustedPR author is trusted by repo permissions or the VOUCHED list.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Kiro's status check gives
kiro-cli --version4 seconds. A healthy CLI that starts slowly loses that race. Common causes are a cold start, a shim, a version manager, or antivirus scanning. When it loses, the check reports an error, "Failed to runkiro-cli --version.", with no version, and Kiro shows as Unavailable until a later check happens to answer within 4 seconds.#28400 fixed this for Grok, Pi and fx by giving
--version10 seconds. Kiro's check uses the same probe pattern but still has the shared 4 second default.Change
Kiro gets the same local
VERSION_PROBE_TIMEOUT_MS = 10_000that Grok, Pi and fx use, and onlykiro-cli --versionuses it. Thewhoami, model-list and agent probes already allow 10 seconds and do not change. The message text does not change. A CLI that really hangs still times out, now after 10 seconds.Scope and approval
Very small, focused fix for an obvious bug, so no prior issue: this applies the change accepted in #28400 to the one sibling status check that #28400 did not reach. It is a 4 line change in one file plus a test.
Overlap search: the local PR index and GitHub search for Kiro, version and timeout found no PR about this. #24676 (open) does the same for Muse and touches only
provider-muse. #28400 covered Grok, Pi and fx only.Verification
apps/server/src/provider/KiroProvider.test.ts: added a table next to the existing Kiro status tests, built like the fix(providers): slow Grok, Pi and fx starts no longer show as unavailable #28400 tests and run on the test clock advanced 10 seconds. The fake process holds back both its output and its exit.--versionanswers after 6 seconds: onmainthis fails withAssertionError: expected 'error' to equal 'ready'. With the fix the snapshot is ready, with version 2.27.0.--versionnever answers: the existing "Failed to runkiro-cli --version." result still comes back.vp test run src/provider/KiroProvider.test.ts: 12 passed.vp run check:changed: passed (format, lint, knip, typecheck of 10 packages, tests 13/13).Runtime check: I ran the real
checkKiroProviderStatuswith real child processes against a fakekiro-clithat sleeps 6 seconds before printing its version and reports signed out:Not checked: a real slow Kiro install, and captures in a client. The status text is the same text the existing error path already shows.
Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.
Created with Claude Opus 5.5 in Claude Code (T3 Code).
🤖 Generated with Claude Code