fix: repair orphaned running tool parts; stop a directory 403 from killing the TUI

[wqymi]

Two independent robustness defects. Both are small and both are about surviving an
interruption, so they ride in one PR; the diffs do not overlap and can be reviewed
section by section.

A — orphaned running tool parts are never repaired

A tool part is persisted as running the moment the tool STARTS, deliberately, so the
TUI can stream progress (prompt.ts:1037/1461/1677, processor.ts:496). Only the abort
finalizer in SessionProcessor.cleanup rewrites it, and that finalizer iterated the
in-memory ctx.toolcalls map of the owning process (processor.ts:743-759). Every
exit path that skips it leaves the DB row at running forever: process kill, crash, dev
restart, a second interruption after ctx.toolcalls = {}, a readToolCall miss, or the
250 ms Deferred.await(...).pipe(Effect.timeout("250 millis")) window. There was no
startup or session-load repair anywhere (session/index.ts, storage/db.ts: zero hits).
Live evidence, re-measured across the whole store: **168 orphaned tool parts (126 running

• 42 pending) across 92 sessions**; in one two-week-old session completed 2474 / error 105 / running 48, of which exactly one was genuinely in flight — i.e. a per-interruption leak.

This is NOT the empty-content provider 400 — proven by wire-level construction

This shape was investigated as a candidate producer of messages.<N>: user messages must have non-empty content and excluded. The exclusion is now a construction, not an
argument: a prompt captured from a real LanguageModelV3.doStream shows that an assistant
message whose ONLY part is an orphaned running/pending tool part converts to

assistant([tool-call])  +  tool([tool-result { type: "error-text",
                                               value: "[Tool execution was interrupted]" }])

yielding zero empty-content messages. message-v2.ts:886-899 (the correct lines; an
earlier revision of this description cited the stale :872-883) matches both
discriminants and substitutes a hard-coded non-empty literal that no data can empty, and
ai@6.0.168's empty-text strip (dist/index.mjs:1424) lives in the role:"user" branch
and only inspects type:"text" parts — it never drops a tool-result from a role:"tool"
block. So no tool part in any state can yield content: [].

The timeline agrees: 74 recorded 400s span 2026-07-14 → 07-28 while the first orphan-only
assistant message in that session is 2026-07-28, so 62 of 74 predate the shape, and 6 of
the 7 sessions carrying the shape have zero 400s. The real producer was a bare-string
continuation turn in ProviderTransform.ensureTrailingUserMessage — see #1948.

So the defect fixed here is data hygiene and UI truthfulness, not provider legality: the
transcript permanently shows tool calls that will never finish. It never touches the
persisted row today.

Fix, two layers:

• cleanup() gets a second, DB-driven pass over the assistant message's own tool
  parts (MessageV2.parts(ctx.assistantMessage.id)), so a call whose registration raced
  teardown, arrived after the map was cleared, or whose readToolCall lookup missed is
  still finalized. Every tool part of that message belongs to the turn being torn down,
  so any part still pending/running is unfinalized by definition. Idempotent.
• SessionPrompt.sweepOrphanToolParts repairs rows a previous process left behind,
  at the same recovery point as the existing sweepOrphanAssistants (start of prompt()
  for non-spawn/hook sources).

Safety of the sweep's scoping

A currently executing tool part is also running, so a naive "rewrite every running row"
sweep corrupts live turns. Two guards, both required, and the gate lives inside the
function rather than in the caller contract:

1. Session status must be idle. busy/retry mean an active runner owns the
   session, and a tool can only execute inside a runner's turn. Same argument the shipped
   sweepOrphanAssistants caller relies on.
2. Main slice only (sessions.messages default). SessionProcessor publishes status
   for the main slice only (if (isMain) status.set(...)), so a subagent slice can be
   executing tools while the session status reads idle — its parts are out of scope.

Both finalizers now share MessageV2.abortedToolState, so an interrupted part has one
consistent shape (status: "error", error: "Tool execution aborted",
metadata.interrupted: true, original time.start preserved).

B — a rejected directory 403 killed the TUI

server/routes/instance/middleware.ts rejects any directory outside the server cwd
(except the app-owned orchestrator workspace) with a 403. The generated SDK throws the
parsed response body with no status attached, so sync.tsx's bootstrap catch could
not tell a policy rejection from a broken server and ran await exit(e) — destroying the
renderer. A user who picked a non-whitelisted worktree lost their entire session.

The whitelist is correct policy and is unchanged. Only its recognisability and client
handling change:

• the 403 body now carries a stable code: "directory_not_allowed" plus the rejected
  directory (new leaf module instance/access.ts owns the code + guard so the TUI does
  not import the server's instance/bootstrap graph);
• bootstrap classifies that error as recoverable and rethrows instead of exiting;
  everything else is still fatal;
• the worktree switch restores the previous directory, re-syncs, and toasts
  Cannot switch to <dir>: outside this server's working directory.

Tests

test/session/prompt-orphan-tool-parts.test.ts (6) — an orphaned running part is
repaired when idle; it is not touched while the session is busy, nor while it is
retry; completed parts are untouched; abortedToolState shape.

test/cli/tui/bootstrap-directory-denied.test.tsx (2) — a 403 from the middleware never
reaches the fatal-exit path (exit is never invoked and the error is handed to the
caller); a non-403 bootstrap failure still exits.

Revert probes (each src change reverted alone):

• remove the idle gate → both safety tests fail with Expected: "running" / Received: "error"
  (exactly the live-turn corruption the gate prevents);
• neuter the repair → Expected: "error" / Received: "running";
• restore if (fatal) → expect(failure).toBeDefined() fails, Received: undefined
  (bootstrap exited instead of surfacing), while the "still exits" test keeps passing.

bun typecheck exit 0.

Test suites compared against a pristine origin/main worktree with the identical command
(bun test test/session/ test/cron/ test/cli/tui/ --timeout 120000), the two runs
executed side by side:

	pass	skip	fail	files
pristine origin/main (60af8f1)	1015	12	10	124
this branch	1023	12	10	126

+8 pass / +2 files is exactly the two new test files. The failure sets are byte
identical (diff of the sorted (fail) lines is empty) — 10 pre-existing failures in the
session/loop busy/cancel/queue group, which flake under concurrent suite load and fail
the same way without this change.

Live-verified against mimo/mimo-v2.5 in an isolated dev home: selecting a worktree
outside the server cwd shows the toast, leaves the transcript intact, and the session
still answers a following turn.