[bwachman]

Summary

• A pending agent reload, such as the one queued when MCP servers finish connecting, now waits for the reactor's current message run to end, not only for the send or approval hand-over to settle. An approval-resumed tool call and the inference after it are no longer torn down mid-run.
• Every agent build logs its reason (initial, reload, interrupt, session-rotation), so a rebuild is visible in the log.
• Newly connected MCP tools take effect after the current run ends rather than partway through it.
• Approvals resumed by a reactor rebuilt after a restart do not open a message run yet, so this deferral does not cover them; CL-10777 tracks that.

Verification

• bun run check and bun run test pass (9198 tests) on top of the run.json snapshot changes in main
• The new runner test fails on main (the agent rebuilds during the approval-resumed run) and passes on this branch
• Existing reload, interrupt, /clear and /new runner tests pass unchanged

Fixes CL-10766
Part of CL-10763

[linear-code]

CL-10763

CL-10766

[TheGreatAxios]

Review · Request changes

A pending reload now waits out the same open message run, including an approval resume. A synchronous handoff to the next run still rebuilds before that run is tracked.

Findings

• src/tui/runner/exit.ts:484 — message.run.ended drops the run and calls reloadIfIdle before the following message.run.started is applied. The reactor emits that pair with no await when it dequeues an uncorrelated message.received (vendor/intx-inference/src/reactor.ts:1635). The stream buffers the start (vendor/intx-agent/src/stream.ts:69). enqueue schedules the rebuild as an earlier microtask than that start (src/tui/delivery-queue.ts:437), so both busy checks see an empty openMessageRuns and closeAgentForRebuild runs. Compaction continuation, a queued steer, or any other uncorrelated deliver during a deferred MCP reload tears the agent down at the start of the next run. If the superseded run had committed a pending approval, the new reactor can re-arm it.

Notes

• The same-run case holds. closeMessageRun is not called on suspend or between the resumed tool and the following inference. A regression that feeds message.run.ended and the next message.run.started in one burst, and asserts no rebuild until the successor run ends, would lock this.

[TheGreatAxios]

Review · Request changes

A pending agent reload waits until the reactor's message run ends, and a one-macrotask re-check keeps a buffered successor run from being torn down at the hand-off.

Findings

• src/tui/runner/exit.ts:477 — buildLiveAgent clears openMessageRuns so a run abandoned by interrupt or rotation cannot keep the session busy, but it leaves pendingReload set and does not call reloadIfIdle. Interrupt (exit.ts:679) and session rotation (exit.ts:785) both rebuild through that helper. A reload that already deferred because the run was open (reloadIfIdle returns at exit.ts:502 while agentBusy() is true, and only clears the flag at exit.ts:503 once it proceeds) stays armed. message.run.ended (exit.ts:464-466) is the path that would have consumed it, and reactor shutdown does not emit that event for the abandoned run. The next message.run.ended or inFlight drop therefore sees an idle agent and builds again, closing the agent interrupt or /clear just created — including one that already picked up the tools the reload was waiting on. Clear pendingReload in buildLiveAgent when it drops those runs, since that build is the reload.

[corbits-triage]

Triage: Pass

No changes needed from you. A maintainer will review this pull request.