Fix Kiro CLI timeout fallback

[txarly89]

Summary

• prefer semantically validated pipe-backed Kiro CLI probes for current releases
• retain a same-deadline PTY fallback for older or terminal-required Kiro CLIs
• make stdout/stderr, cancellation, process cleanup, and app-shutdown ownership deterministic
• add focused regressions for pipe, PTY, partial output, auth, deadlines, cancellation, and process cleanup

Closes #1883.

Root cause

Current Kiro CLI releases can return normally through pipes but stall when launched directly under a PTY. Older releases had the inverse behavior and required a terminal. The original candidate retried PTY only after a thrown pipe timeout, so incomplete or noisy pipe output could bypass the fallback, and each transport could consume a fresh timeout budget.

Implementation

• validate pipe results per command before accepting them; incomplete output falls through to PTY
• keep authentication failures and parseable nonzero failures authoritative instead of masking them with a retry
• use one monotonic deadline across pipe execution, cleanup, and PTY fallback
• combine stdout and stderr deterministically and drain both concurrently
• fully terminate/reap pipe roots, descendants, and output holders before starting PTY
• register pipe PIDs/process groups with the app-shutdown registry
• preserve cancellation before launch, between transports, during cleanup, and before return

Validation

• swift test --filter KiroStatusProbeTests: 54/54 passed
• make check: passed; SwiftFormat and SwiftLint clean
• make test: all 50 shards passed on the exact candidate
• independent exact-diff review: clean
• dependencies unchanged

Signed packaged helper proof at 5787a81a:

• strict code-sign verification and Gatekeeper assessment passed for Developer ID team Y5PE65HELJ
• bundle metadata reports commit 5787a81a; helper reports CodexBar 0.41.1
• three varied pipe-only runs returned the exact quota and context values without PTY
• three varied terminal-required runs used pipe then PTY, returned the exact values, and showed no overlap or leftover processes
• mixed stdout/stderr preserved identity and quota data
• stderr authentication rejection surfaced Not logged in without PTY fallback
• a hanging fixture exhausted one shared deadline in 10.38s, emitted one timeout result, and left its recorded PID dead
• installed Kiro CLI 2.12.0 logged-out behavior was reverified with --version and whoami only; no login flow, Keychain, browser-cookie, or provider-network probe was triggered

Remaining merge gate

This machine has no approved logged-in Kiro account. The transport behavior is proven against the exact signed helper, but a real authenticated positive call remains unavailable. Keep this PR draft until an exact-head authenticated run is supplied by the contributor or a maintainer explicitly waives that final provider-access proof.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 9, 2026, 3:57 PM ET / 19:57 UTC.

Summary
The PR changes Kiro status probing to try bounded pipe-backed CLI execution before PTY, adds pipe-only and PTY-only regression tests, and adds a Kiro changelog entry.

Reproducibility: no. high-confidence local reproduction by this review: the linked issue has live signed-app terminal evidence and current main shows the PTY-only timeout path, but I did not run live Kiro provider probes under repository policy. The PR's compatibility gap is source-reproducible from the new pipe result and validation boundaries.

Review metrics: 2 noteworthy metrics.

• Touched surface: 3 files changed; 1 provider runner, 1 test file, 1 changelog entry. The review risk is concentrated in Kiro process transport rather than broad UI or settings code.
• Transport behavior: 1 new pipe-first path plus PTY fallback. Changing the execution transport affects compatibility with both current and older Kiro CLI releases.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1883
Summary: This PR is a candidate fix for the canonical Kiro timeout tracker, with one closed duplicate carrying the same timeout symptom.

Members:

• canonical: Kiro timeout #1883 - The PR body uses closing syntax for this issue, and an owner comment identifies it as the canonical tracker for the post-v0.38 Kiro timeout.
• duplicate: Kiro provider always times out ("Kiro CLI timed out.") despite kiro-cli working fine standalone #1957 - The canonical issue discussion identifies this closed report as a duplicate reproducing the same Kiro timeout on v0.39-v0.40/Kiro 2.11.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦐 gold shrimp
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted after-fix terminal output or logs from the patched CodexBarCLI showing Kiro usage succeeds.
• Extend the fallback and tests so partial or noisy pipe output that is not a usable completion falls back to PTY.
• Run the focused KiroStatusProbe tests or cite CI with a full Xcode toolchain once available.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR links terminal evidence for the released-app failure and a pipe-output experiment, but I did not find after-fix proof from the patched app or CLI; add redacted patched-run terminal output, logs, or a recording, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• [P1] Merging as-is can regress older Kiro CLI releases or edge cases that emit partial stdout/stderr over pipes but still require PTY for a complete usage snapshot.
• [P1] The PR body shows live failure evidence and a pipe-output experiment, but not a patched CodexBarCLI or app run proving the submitted branch fixes Kiro usage end to end.
• [P1] The PR body says focused tests could not run under the contributor's local Command Line Tools setup, so full Xcode validation is still pending CI or maintainer verification.

Maintainer options:

1. Complete fallback coverage before merge (recommended)
   Treat incomplete, idle, nonzero, or unparsable pipe output as a reason to try the existing PTY path, and cover that with a focused fake-CLI regression.
2. Accept older-Kiro compatibility risk
   Maintainers could merge the pipe-first behavior as-is only if they intentionally decide that partial-output pipe edge cases no longer need PTY compatibility.

Next step before merge

• [P2] Not a ClawSweeper repair candidate while this external PR lacks after-fix real behavior proof; the contributor should address the fallback finding and attach redacted patched-run proof.

Security
Cleared: No concrete security or supply-chain issue was found; the diff changes local Kiro process transport and tests without new dependencies, CI, secrets handling, or downloaded code.

Review findings

• [P1] Retry PTY after unusable pipe output — Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:478-482

Review details

Best possible solution:

Keep the pipe-first transport, but make PTY fallback happen for any pipe result that is not a validated usable completion, add a partial/noisy pipe-output regression, and attach redacted after-fix CodexBarCLI proof for Kiro 2.12.

Do we have a high-confidence way to reproduce the issue?

No high-confidence local reproduction by this review: the linked issue has live signed-app terminal evidence and current main shows the PTY-only timeout path, but I did not run live Kiro provider probes under repository policy. The PR's compatibility gap is source-reproducible from the new pipe result and validation boundaries.

Is this the best way to solve the issue?

No as-is: pipe-first with PTY fallback is the right shape, but fallback must include unusable pipe results, not only thrown pipe timeouts. A narrow code/test repair is preferable to adding a timeout knob or replacing the whole provider path.

Full review comments:

• [P1] Retry PTY after unusable pipe output — Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:478-482
  The PTY fallback only runs when runViaPipe throws .timeout; if the pipe path emits any stdout/stderr and then idles, runViaPipe returns a result, and the later validateCommandCompletion or parse error happens outside this catch. That means an older Kiro CLI that produces a prompt, banner, or progress line over pipes without a complete /usage snapshot will now fail instead of taking the existing PTY path. Please validate the pipe result before committing to it, or make incomplete/idle pipe output fall through to runViaPTY and add a regression for that case.
  Confidence: 0.78

Overall correctness: patch is incorrect
Overall confidence: 0.81

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 58b1cd5af2f8.

Label changes

Label changes:

• add P2: The PR addresses a real Kiro provider timeout with limited blast radius to one provider's usage refresh path.
• add merge-risk: 🚨 compatibility: The new pipe-first transport can skip PTY fallback on partial or noisy pipe output, potentially breaking older Kiro setups that currently rely on PTY execution.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR links terminal evidence for the released-app failure and a pipe-output experiment, but I did not find after-fix proof from the patched app or CLI; add redacted patched-run terminal output, logs, or a recording, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.

Label justifications:

• P2: The PR addresses a real Kiro provider timeout with limited blast radius to one provider's usage refresh path.
• merge-risk: 🚨 compatibility: The new pipe-first transport can skip PTY fallback on partial or noisy pipe output, potentially breaking older Kiro setups that currently rely on PTY execution.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR links terminal evidence for the released-app failure and a pipe-output experiment, but I did not find after-fix proof from the patched app or CLI; add redacted patched-run terminal output, logs, or a recording, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its provider guidance affected the review by keeping validation to source, focused tests, and supplied terminal evidence instead of live Kiro probes that could touch real auth/provider state. (AGENTS.md:1, 58b1cd5af2f8)
• Current main behavior: Current main still runs Kiro usage and context requests through the PTY runner and validates PTY completion, which is the behavior this PR replaces with a pipe-first transport. (Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:418, 58b1cd5af2f8)
• PR fallback boundary: The PR only retries PTY when runViaPipe throws KiroStatusProbeError.timeout; idle pipe results with any output return to later validation/parsing outside that catch. (Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:478, 83dc40bfec3e)
• Linked issue and proof context: The linked canonical issue contains maintainer confirmation that the v0.38-v0.41 PTY work is already shipped, plus sanitized terminal evidence that CodexBar 0.41.0 times out while direct Kiro CLI usage succeeds and a pipe-output experiment returns a snapshot.
• Feature history: Git history shows the relevant Kiro transport path was recently changed by the PTY fix, earlier pipe-hang work, account-probe timeout handling, and release integration. (Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift)
• Maintainer notes check: No matching .agents/maintainer-notes directory was present in the checkout, so there were no private maintainer notes to apply for this diff.

Likely related people:

• steipete: Current relevant lines blame to the v0.41.0 release snapshot, and history shows recent Kiro/provider runtime work around usable providers and helper cleanup. (role: recent area contributor and release integrator; confidence: high; commits: a83a83fa4131, 68939add9bff, 3286934b8be3; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift)
• sf-jin-ku: Authored the merged PTY transport work that this PR now wraps with a pipe-first fallback. (role: recent transport contributor; confidence: high; commits: da693aa7ce9f; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift, Tests/CodexBarTests/KiroStatusProbeTests.swift)
• kiranmagic7: Authored prior Kiro usage command pipe-hang work on the same probe and test surface. (role: adjacent pipe-path contributor; confidence: medium; commits: 209b6c857fad; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift, Tests/CodexBarTests/KiroStatusProbeTests.swift)
• Yuxin Qiao: Authored account-probe timeout handling on the same Kiro fetch path shortly before this report. (role: recent timeout contributor; confidence: medium; commits: 8009f70b60ac; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift, Tests/CodexBarTests/KiroStatusProbeTests.swift)
• Nathan Eror: Introduced the Kiro provider and initial AWS kiro-cli usage tracking implementation now involved in the timeout path. (role: introduced behavior; confidence: medium; commits: bbda93528714; files: Sources/CodexBarCore/Providers/Kiro/KiroProviderDescriptor.swift, Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Maintainer repair pushed at exact head 5787a81abee53158cb5c5ef1a0c5fe3d4a5c4e0c.

Proof completed:

• focused Kiro suite: 54/54 passed
• make check: passed
• full local suite: all 50 shards passed
• exact-diff review: clean
• signed packaged helper: strict signature + Gatekeeper accepted; bundle commit 5787a81a
• source-blind matrix: 3 pipe-only + 3 terminal-required runs with varied values, noisy stderr, auth rejection, one-deadline hang cleanup; all expected behaviors passed and no process remained
• real Kiro CLI 2.12.0: version and logged-out whoami behavior verified without starting login or touching credentials
• Public Model Identifier Gate: PASS; dependencies unchanged

Remaining merge gate: this machine has no approved logged-in Kiro account. @txarly89, if you have an authenticated Kiro setup, please run this exact head through the freshly packaged helper and share a redacted positive result (helper/bundle commit, Kiro CLI version, three refresh timings, parsed quota/context presence, and confirmation that no Kiro process remains). Do not include account or credential values. Otherwise a maintainer must explicitly waive that final provider-access proof.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29075730190
• Updated: 2026-07-10T07:13:53.611Z

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: Fix Kiro CLI timeout fallback This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.