Codex review: needs maintainer review before merge.

Summary
The branch adds an outer embedded-run idle-timeout breaker, a pure helper with unit tests, and a changelog entry for the linked runaway cost bug.

Reproducibility: yes. By source inspection, current main recreates the idle watchdog per embedded attempt and only has a broad 32-160 iteration backstop, while #76293 supplies concrete zero-output timeout storm evidence; I did not run a live paid-provider reproduction.

Next step before merge
No repair job: this is an active contributor PR with no discrete actionable defect from this pass, so the remaining path is normal review and CI gating.

Security
Cleared: The diff only changes local TypeScript run-loop logic, a colocated unit test, and CHANGELOG.md; it does not touch dependencies, workflows, package scripts, permissions, or secrets.

Pushed f3a4a5d to fix the check-test-types failure I introduced. Was: driveTimeouts cast {} to Parameters<typeof params.baseFn>[N], but the passed-in baseFn has the broad ReturnType<typeof vi.fn> type which does not satisfy Parameters<>'s (...args: any) => any constraint, so tsc bailed with TS2344 on lines 268-270. Now: import StreamFn from @mariozechner/pi-agent-core (same import the production file uses), derive StreamFnArgs = Parameters<StreamFn>, and cast the tuple straight to that.

The other two failures are pre-existing on main and unrelated to this PR:

• check-additional-boundaries is the lint:tmp:no-raw-channel-fetch check flagging raw fetch() in extensions/chutes/models.ts:536,543 and extensions/huggingface/models.ts:143. I haven't touched any of those files
• checks-fast-contracts-plugins-c is extensions/tlon keeping the unused dependency @tloncorp/tlon-skill. Same, not mine

Per CONTRIBUTING.md ("Do not submit test or CI-config fixes for failures already red on main CI"), leaving those two alone for the maintainer team to track.

Pushed 06e7ef9 addressing the clawsweeper [P2] and [P3] findings.

[P2] Counter moved from wrapper to outer run loop. The bot was right: the per-attempt session and streamWithIdleTimeout wrapper installed at attempt.ts:2145 get recreated on every iteration of runEmbeddedAttemptWithBackend in run.ts:927, so a wrapper-local counter resets every time and the cap never trips on the actual retry path. v1 was theater. v3 puts the state in run.ts next to sameModelIdleTimeoutRetries (so it survives across attempts AND across profile/model failover), updates it right after the attempt is destructured (run.ts:1188), and bails through the existing handleRetryLimitExhaustion path with a distinct error message when the cap is hit. The wrapper at llm-idle-timeout.ts is restored to its original upstream shape, no behavior change there.

The "no model output" gate. The breaker only counts attempts where attemptUsage.output === 0 AND idleTimedOut, so a slow-but-responsive stream that produced 200 tokens then idle-timed-out at the tail is NOT treated as a wedged provider. Resets the moment any attempt produces output. Reserved specifically for the truly-no-output wedge that drove the reporter's incidents.

Tests rewritten as integration tests in src/agents/pi-embedded-runner/run.idle-timeout-breaker.test.ts using the existing run.overflow-compaction.harness:

1. 12 wedged attempts queued, mockedRunEmbeddedAttempt called exactly 5 times, error message matches /cost-runaway breaker tripped/
2. 8 productive-but-timed-out attempts queued, breaker stays disarmed
3. 4 wedged + 1 productive + 4 wedged queued, breaker stays disarmed because the productive attempt resets the counter between the two runs of 4

The 5 wrapper-level unit tests from v1 were removed (the behavior they covered no longer exists in the wrapper). llm-idle-timeout.test.ts is back at the upstream shape.

[P3] CHANGELOG entry. Added an Unreleased Fixes line under Agents/idle-timeout referencing #76293, matching the existing voice in that section.

Acceptance commands per the bot's review:

• pnpm test src/agents/pi-embedded-runner/run/llm-idle-timeout.test.ts src/agents/pi-embedded-runner/run.idle-timeout-breaker.test.ts (substituted my new file for the compaction one since this is the run-loop test for this fix)
• pnpm exec oxfmt --check and pnpm check:changed would be next, but pnpm is not installed in my sandbox so relying on PR CI for those.

Diff is now +186/-232 (net negative). Marking as ready for re-review.

Pushed 27ff168 addressing clawsweeper [P3]: added Thanks @ThePuma312 to the changelog entry, since they filed #76293. No code change, just the credit.

Bot's [P2] / architectural concern from the previous review is fully resolved on the rebased branch — counter lives at the run loop level next to sameModelIdleTimeoutRetries, not in the wrapper, integration tests cover the actual loop via the existing harness. Re-review summary marked patch as correct with confidence 0.86.

CI on the prior commit was 77 success / 21 skipped / 1 neutral with one in-progress check (the pre-existing main-failure that doesn't gate this PR). Will let it ride.

Pushed c87d455 addressing both clawsweeper [P2] findings on the integration test.

You were right on two counts: (1) the v3 integration test asserted exactly 5 mocked attempts but with the harness default mockedResolveAuthProfileOrder of [], the run loop only allows ~2 attempts before bailing through assistantFailoverOutcome.throw, so the assertion was unreachable. (2) On top of that, the file naming run.idle-timeout-breaker.test.ts did not match the existing agents test shard's glob, so the test was never being executed in CI in the first place. Two layers of broken.

Fix: extracted the breaker into a pure helper at src/agents/pi-embedded-runner/run/idle-timeout-breaker.ts with MAX_CONSECUTIVE_IDLE_TIMEOUTS_BEFORE_OUTPUT, createIdleTimeoutBreakerState(), and stepIdleTimeoutBreaker(state, input, opts?). run.ts owns the state at the outer-loop scope (next to sameModelIdleTimeoutRetries), calls the helper after each attempt is destructured, and bails through the existing handleRetryLimitExhaustion path when step.tripped is true. Same product behavior as v3, just with the logic in a place that can be exercised directly.

New tests at src/agents/pi-embedded-runner/run/idle-timeout-breaker.test.ts (sibling shard to the existing run/llm-idle-timeout.test.ts so it actually gets picked up). 9 cases covering: default cap matches the constant the run loop reads from; one wedged attempt does not trip; five wedged in a row trips; explicit smaller cap respected; cap=0 escape hatch; slow-but-alive (timeout but produced output) never trips; productive attempt between two runs of 4 wedged resets the counter; non-timeout error attempts neither poison nor reset; defensive coercion of NaN/negative/Infinity outputTokens to 0.

Deleted the v3 run.idle-timeout-breaker.test.ts (the unreachable, never-executed one).

CHANGELOG entry from v3 unchanged (this is a refactor of the implementation, not a behavior change). Same product fix.

The breaker location is correct: outer-loop scope survives same-model retries and attempt boundaries, helper is pure + well-tested, five-call worst-case bound on the reported $20-30 incident pattern.

Tool-call-only attempts may falsely reset the breaker. attemptUsage?.output (run.ts:1180) reflects aggregate provider output tokens, not text-only. Tool-call argument deltas stream incrementally before completion (openai-transport-stream.ts:477,484) and the idle watchdog races each iterator next() (llm-idle-timeout.ts:121,129), so a wedged provider that emits partial tool args before stalling would report outputTokens > 0 → reset to 0 (helper line 333). Worth a test case for idleTimedOut: true, outputTokens > 0 from tool-args only and a decision on whether to count text-output-only.

Failover state persistence is split. Profile rotation within one runEmbeddedPiAgent invocation persists the counter (outer-loop scope). Model fallback goes through runAgentAttempt → agent-command.ts:985 → command/attempt-execution.ts:561 → fresh runEmbeddedPiAgent invocation, which resets idleTimeoutBreakerState. The CHANGELOG claim "fires regardless of failover" likely doesn't hold for the model-fallback path. Confirm and either tighten the changelog or hoist state to the surviving scope.

Observability — distinct trip signal. The trip routes through handleRetryLimitExhaustion and reuses generic retry_limit (retry-limit.ts:27,41). Operators reading logs/metrics can't distinguish a cost-runaway trip from ordinary retry exhaustion. Worth a distinct log tag ([idle-timeout-circuit-breaker-tripped]) or error-kind metadata so dashboards can alert separately.

Hardcoded cap (non-blocking). Helper accepts options.cap but the call site uses the default. Existing timeouts surface through config (types.agent-defaults.ts:340/384/496); follow-up agents.idleTimeoutBreakerCap would let ops teams tune by paid-vs-free-tier.

Addressed the tool-call-only reset concern in bc82066.

• src/agents/pi-embedded-runner/run.ts now resets the breaker only for completed model progress: non-empty assistant text, completed regular/hosted tool calls, messaging-tool delivery evidence, or completed item lifecycle.
• src/agents/pi-embedded-runner/run/idle-timeout-breaker.ts intentionally ignores raw outputTokens as the reset signal, so billed partial tool-argument deltas before an idle stall still count toward the breaker.
• src/agents/pi-embedded-runner/run/idle-timeout-breaker.test.ts adds the regression case for idleTimedOut: true with positive outputTokens but no completed progress.
• Also tightened the changelog wording to “same embedded run” and added a distinct [idle-timeout-circuit-breaker-tripped] log tag.

Local/Testbox proof:

• pnpm test src/agents/pi-embedded-runner/run/idle-timeout-breaker.test.ts
• pnpm exec oxfmt --check --threads=1 src/agents/pi-embedded-runner/run.ts src/agents/pi-embedded-runner/run/idle-timeout-breaker.ts src/agents/pi-embedded-runner/run/idle-timeout-breaker.test.ts
• Testbox pnpm check:changed on tbx_01kqpz2cptpq5fbvvbcywvmht5

Landed via rebase onto main.

• Gate: exact-head CI green; local helper test and Testbox pnpm check:changed passed.
• Source head: bc82066
• Landed commit: 8f20d03

Thanks @adhirajhangal!