fix: restore Kiro usage refresh across CLI transports#2012
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 11, 2026, 10:26 PM ET / July 12, 2026, 02:26 UTC. Summary Reproducibility: yes. The canonical report shows a repeatable CodexBar timeout with successful standalone commands, and exact-head real-process fixtures reproduce both conflicting transport requirements; authenticated live confirmation is a proof gap rather than a reproduction gap. Review metrics: 3 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Land the dual-transport repair after a redacted authenticated packaged-helper run or an explicit maintainer waiver, while retaining both transport-mode process fixtures as regression coverage. Do we have a high-confidence way to reproduce the issue? Yes. The canonical report shows a repeatable CodexBar timeout with successful standalone commands, and exact-head real-process fixtures reproduce both conflicting transport requirements; authenticated live confirmation is a proof gap rather than a reproduction gap. Is this the best way to solve the issue? Yes. The final design gives a viable pipe the full deadline, starts PTY opportunistically, semantically selects results, uses the enriched environment, and drains structured cancellation and cleanup without removing legacy compatibility. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 3560c3dd589d. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
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
Review history (4 earlier review cycles)
|
83dc40b to
5787a81
Compare
|
Maintainer repair pushed at exact head Proof completed:
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 |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Co-authored-by: Txarly89 <cargonza99@gmail.com>
5787a81 to
86d3f2e
Compare
|
@clawsweeper re-review Maintainer repair is complete on exact head |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 86d3f2e1ff
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| { | ||
| let clock = ContinuousClock() | ||
| let deadline = clock.now.advanced(by: .seconds(max(0, timeout))) | ||
| let pipeBudget = min(max(0, self.pipeTimeoutCap), max(0, timeout / 2)) |
There was a problem hiding this comment.
Allow pipe-only CLIs to use the full timeout
When a current Kiro CLI only works through pipes, this caps the only usable transport to 5 seconds of the 20-second usage deadline. If kiro-cli chat --no-interactive /usage has a cold start or network delay and produces its first output after 5 seconds but before the documented 20-second timeout, runViaPipe kills it and the PTY fallback is exactly the transport that stalls, so refresh still fails even though the command would have completed within the configured deadline.
Useful? React with 👍 / 👎.
| let stdoutPipe = Pipe() | ||
| let stderrPipe = Pipe() | ||
|
|
||
| var env = ProcessInfo.processInfo.environment |
There was a problem hiding this comment.
Use the enriched PATH for pipe launches
In the macOS app environment, PATH often lacks Homebrew/npm locations; cliBinaryResolver can still find kiro-cli via the login-shell PATH, but launching the resolved shim with raw ProcessInfo means interpreters such as #!/usr/bin/env node cannot be found. For current Kiro versions that need the pipe transport, the subsequent PTY fallback may stall, so these installs never refresh usage. Build this environment with the same enriched PATH used by TTYCommandRunner.
Useful? React with 👍 / 👎.
|
Maintainer verification at exact head
No real Kiro account was available, so account-authenticated refresh was not exercised. The transport behavior and parser outcomes are covered by the focused regressions and the process-level smoke proof above. Hosted CI passed lint, Linux x64/arm64, and macOS shard 1. macOS shard 0's only failure was the unrelated Kimi timing assertion measuring 253.38 ms against a strict 250 ms threshold; the failed exact-head shard was rerun before landing. |
Summary
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
Validation
7846f59bc3ebebd87ff8432b8d016ca1e61f8b6f, rebased onto currentmainafter fix: isolate interactive PATH probes from caller terminal #2074.make check: SwiftFormat and SwiftLint clean.Live-provider limitation
This machine does not have
kiro-cliinstalled or an approved logged-in Kiro account, so a real authenticated provider request was intentionally not attempted. The transport state machine and OS-process behavior are covered by the exact-head integration matrix; contributor and maintainer authorization to land this repair waives the unavailable account-dependent proof.