Summary

The circuit breaker in manager.ts fails to detect repeated tool_use loops (Kimi K2.6 reading the same file 20+ times) because it tracks only partInfo.state?.input, which is null until the tool transitions to running. The signature-based deduplicator then alternates between tool::__unknown-input__ and tool::{actual-input} on every event, repeatedly resetting consecutiveCount to 1 and never reaching the threshold.

Fall back to partInfo.input (the part's top-level input, available as soon as the tool_use block is emitted) when state.input is unavailable so the signature stays stable across the model's repeated emissions.

Root Cause

src/features/background-agent/manager.ts line 1354-1359 (inside the message.part.updated / message.part.delta handler):

```typescript
task.progress.toolCallWindow = recordToolCall(
task.progress.toolCallWindow,
partInfo.tool,
circuitBreaker,
partInfo.state?.input // <-- null until status="running"
)
```

The reporter traced the symptom: when Kimi K2.6 generates 20+ identical `tool_use` blocks, those parts arrive on `message.part.updated` with `state` still empty (no `status`, no `input`). `recordToolCall` receives `undefined`, falls into the "unknown input" branch in `loop-detector.ts:39-44`, and produces signature `read::unknown-input`. The next event for the same part finally has `state.input` populated, signature flips to `read::{filePath:...}`, `consecutiveCount` resets to 1, and the cycle repeats — so the `consecutiveThreshold: 20` ceiling is never reached.

Changes

Diff: +103 / -1 lines across 2 files.

Reproduction (before fix)

```text
src\features\background-agent\manager-circuit-breaker.test.ts:
expect(received).toBe(expected)

Expected: "cancelled"
Received: "running"

(fail) BackgroundManager circuit breaker > #given duplicate tool_use blocks arrive without state.input but with top-level input > #when 20 identical reads arrive #then circuit breaker still detects the loop

9 pass
1 fail
```

Without the fix, 20 identical `{ tool: "read", input: { filePath: "..." } }` events leave the task in `running` state — the breaker never fires.

Verification (after fix)

```text
bun test src/features/background-agent/manager-circuit-breaker.test.ts
10 pass
0 fail
21 expect() calls
Ran 10 tests across 1 file. [511.00ms]

bun test src/features/background-agent/loop-detector.test.ts
20 pass
0 fail
22 expect() calls

bun run typecheck
$ tsc --noEmit (clean)
```

The new "state.input takes precedence" test confirms the existing semantics are preserved: when both fields are populated, signatures still differentiate per-call.

Test

• Regression tests: 2 new cases in `manager-circuit-breaker.test.ts` (one reproduces the bug, one guards the precedence semantics).
• Related suite: `bun test src/features/background-agent/manager-circuit-breaker.test.ts loop-detector.test.ts` — 30 pass, 0 fail.
• Typecheck: `bun run typecheck` — clean.

Fixes #3962

^{Need help on this PR? Tag @codesmith with what you need.}

• Let Codesmith autofix CI failures and bot reviews

Summary by cubic

Make the circuit breaker use top-level tool input when state.input isn’t available so repeated tool_use loops are detected. Fixes #3962 by preventing infinite reads when models emit input before tools start running.

• Bug Fixes
  • Prefer state.input; fall back to part-level input to keep signatures stable across events.
  • Typed input on MessagePartInfo and pass the resolved input to recordToolCall.
  • Added regression tests to cover top-level-only input and confirm state.input takes precedence.

^{Written for commit 5cd95cf. Summary will update on new commits.}