Kiro usage refresh can hang on process termination or inherited pipes

[steipete]

Problem

Kiro's usage command runner has two unbounded waits in the provider refresh path:

• after timeout/idle termination it calls waitUntilExit() after only sending terminate
• after process exit it calls readDataToEndOfFile() for stdout/stderr, which waits indefinitely when a descendant retains either inherited pipe

That can hold a Kiro provider refresh open after the parent CLI has exited or ignored SIGTERM.

Source reproduction

• a short parent prints output, launches a detached child inheriting stdout/stderr, then exits; the current final EOF reads wait for the child
• a process that ignores SIGTERM can leave the current timeout path blocked in waitUntilExit()

Fix shape

• keep incremental stdout/stderr capture and idle-activity tracking
• bound TERM-to-KILL escalation and post-exit drains
• preserve completed no-output exit statuses for existing caller validation
• add regressions for inherited pipes, ignored SIGTERM, and completed no-output failures
• validate without live Kiro credentials or Keychain access

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 14, 2026, 2:42 PM ET / 18:42 UTC.

Summary
Keep open: this owner-authored issue needs maintainer handling, and current main still has the Kiro usage-runner waits described in the report.

Reproducibility: yes. at source level. Current main still reaches waitUntilExit after terminate and then readDataToEndOfFile on both pipes, which matches the detached-child and ignored-SIGTERM reproduction shapes in the report.

Next step
This is a narrow source-reproducible provider bug with clear files and fake-process tests; it is not strict automatic bug-fix eligible because I did not run a failing current-main harness.

Review details

Best possible solution:

Refactor KiroStatusProbe.runCommand to use the existing bounded pipe-capture and termination pattern, preserve current output validation, and add non-live regressions for inherited pipes, ignored SIGTERM, and completed no-output failures.

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

Yes, at source level. Current main still reaches waitUntilExit after terminate and then readDataToEndOfFile on both pipes, which matches the detached-child and ignored-SIGTERM reproduction shapes in the report.

Is this the best way to solve the issue?

Yes. Bounded TERM-to-KILL escalation plus bounded post-exit pipe capture using the existing ProcessPipeCapture/SubprocessRunner pattern is the narrow maintainable fix, with no new provider capability or config knob needed.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The adjacent open version-probe PR does not by itself fix Kiro usage refresh hangs, so this issue still needs its own patch or an explicit expansion of that PR.
• No live Kiro command was run during review; validation should stay on fake CLI/process tests to avoid credentials or Keychain prompts.

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

Label changes

Label changes:

• add P2: This is a normal-priority provider refresh hang with a clear, bounded subprocess failure mode.
• add impact:crash-loop: The issue is about process availability because Kiro refresh can wait indefinitely on termination or inherited output pipes.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority provider refresh hang with a clear, bounded subprocess failure mode.
• impact:crash-loop: The issue is about process availability because Kiro refresh can wait indefinitely on termination or inherited output pipes.

Evidence reviewed

Acceptance criteria:

• swift test --filter KiroStatusProbeTests
• swift test --filter 'KiroStatusProbeTests|SubprocessRunnerTests'
• make check
• make test

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance favors focused provider/parser tests and forbids live provider or Keychain validation unless explicitly requested. (AGENTS.md:1, ac8159f6b10c)
• Current Kiro usage path: Kiro usage refresh calls runCommand for kiro-cli chat --no-interactive /usage with a 20s timeout and 10s idle cutoff. (Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:341, ac8159f6b10c)
• Unbounded termination wait remains: After timeout or idle detection, runCommand sends terminate and immediately calls waitUntilExit without bounded TERM-to-KILL escalation. (Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:510, ac8159f6b10c)
• Unbounded EOF drains remain: After process exit, runCommand still calls readDataToEndOfFile for stdout and stderr, which can wait for a descendant retaining inherited pipe descriptors. (Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift:519, ac8159f6b10c)
• Existing bounded helper pattern: Current main already has ProcessPipeCapture.finish(timeout:) and SubprocessRunner uses it for bounded post-exit output capture, giving the Kiro fix a narrow local pattern to reuse. (Sources/CodexBarCore/Host/Process/ProcessPipeCapture.swift:22, ac8159f6b10c)
• Regression template exists: SubprocessRunnerTests includes a detached-child inherited-pipe regression that returns captured output without waiting for child EOF. (Tests/CodexBarTests/SubprocessRunnerTests.swift:25, ac8159f6b10c)

Likely related people:

• steipete: Authored the current main bounded subprocess output-draining work and opened the adjacent version-probe fix PR that uses the same helper direction. (role: recent area contributor and likely follow-up owner; confidence: high; commits: ac8159f6b10c, cd9b51955633, 0d75140af3d0; files: Sources/CodexBarCore/Host/Process/ProcessPipeCapture.swift, Sources/CodexBarCore/Host/Process/SubprocessRunner.swift, Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift)
• chadneal: PR history shows Chad Neal introduced Kiro's activity-based idle detection and incremental readabilityHandler capture in PR 145. (role: introduced relevant timeout behavior; confidence: high; commits: a0bb8dd86010; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift)
• neror: PR 114 added the Kiro provider, descriptor, probe, and initial KiroStatusProbe tests. (role: original Kiro provider contributor; confidence: high; commits: bbda93528714; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift, Sources/CodexBarCore/Providers/Kiro/KiroProviderDescriptor.swift, Tests/CodexBarTests/KiroStatusProbeTests.swift)
• solnikhil: PR 933 substantially changed Kiro account, usage, and parsing behavior around the same provider surface. (role: recent Kiro usage contributor; confidence: medium; commits: 9854b21fe141, f7c83fe2c157, 766cb36e560d; files: Sources/CodexBarCore/Providers/Kiro/KiroStatusProbe.swift, Tests/CodexBarTests/KiroStatusProbeTests.swift)

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.