Dor Tools: share Terminal Context and integrate current main

[nedtwigg]

dor tool runs a command and displays its browser in the same Surface. Terminal Context exposes its primary terminal; the Session, Surface handle, scrollback, and notepad survive serving and renderer changes.

Named project Tools use dormouse.yml and visible trust approval before execution. Failed grant writes and post-grant lookups retain the approval and display a persistent error until the next attempt; blank host reasons get a useful fallback. Serving uses the Session's process-tree ports, with OSC 367 selecting a port or automatic discovery refusing ambiguous listeners. Workspace routing, closure, persistence, and movement retain the Tool lifecycle. Refused drag moves display a dismissible explanation, and expired arrivals release without preparing another move. The Tools flag starts off and controls new creation; disabling it does not stop existing Tool commands or serving.

Approval, iframe connection/error messages, and Tool port conflicts share one wrapping, scrollable pane-message layout. Pending approvals retain pane geometry and selection feedback. Narrow and short approval stories include DOM geometry play checks for wrapping and reaching the controls.

Launches and approval completion share a queue through command start or completion. Approved Tools recheck their resolved key before launching; --fresh preserves separate prompts and launches. Reusing a Tool closes and archives the redundant approval first, retaining it without sending input if archival fails.

Serving tracks command-run identity, clears old announcements at each command start, and rediscovers ports after rapid restarts. Announcement changes reuse the current browser session and binary. When the browser retires, terminal focus targets the terminal directly even while the old iframe focus handle is still registered.

Validation coverage: trust receipts, concurrent approval/launch reuse, startup ordering, command-run boundaries, browser cleanup and focus, notes, persistence, Workspace transfer, and both host adapters. No dogfooding or installation.

Local validation: 110 focused library tests, the full standalone suite (229 Vitest tests plus 23 script tests), both TypeScript checks, and spec checks pass. CI and Chromatic run on the pushed head.

Tool stack 1/7, based on main. Next: #514. Merge bottom-up after its predecessors.

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	d44f1c3
Status:	✅  Deploy successful!
Preview URL:	https://4d6caec7.mouseterm.pages.dev
Branch Preview URL:	https://phase-b.mouseterm.pages.dev

View logs

[dormouse-bot]

Big, careful change — the spec/rationale split, the namespaced dedupe keys, and the visibility-not-display flip in ToolPanel all land well. Four inline findings below, plus one that sits outside the diff.

The Door path bypasses persistableLeafMeta, so a minimized tool does persist its URL

persistableLeafMeta is applied only inside serializeLayout, and lathLayoutFromStore keeps only the leaves the tree places — a Doored leaf is deliberately excluded there and persisted as its own row instead. That row is built in use-session-persistence.ts (the doSave callback, const doors: PersistedDoor[] = (doorsRef.current ?? []).map(...)) from lath.getMeta(door.id) verbatim: component, tabComponent, and params: meta?.params. saveSession passes it straight through to doors:, and leafMetaFromPersistedDoor restores params: item.params unchanged.

So minimizing a serving tool before quitting round-trips url, session, wsPort, renderMode, and showTerminal — which docs/specs/dor-tool.md → Persistence and hosts states as "The URL is never persisted."

Concretely: minimize standalone-harness while it is serving, quit, relaunch. If the host's session restore gets the command running again before useToolServing's first tick, the tick takes the hasUrl || !running → continue branch and the stale url is never cleared, so the tool frames last run's port. If the command is not running, the retire branch clears url and showTerminal — but never renderMode, session, or wsPort, so an ab-screencast tool reattaches bound to a daemon session that died with the previous process.

The fix is one line at the door projection — run the meta through persistableLeafMeta before splitting it into the row:

const meta = lath.getMeta(door.id);
const persistable = meta ? persistableLeafMeta(meta) : undefined;
return {
  id: door.id,
  title: persistable?.title?.trim() || UNNAMED_PANEL_TITLE,
  component: persistable?.component,
  tabComponent: persistable?.tabComponent,
  params: persistable?.params,
  token: door.token,
};

use-session-persistence.ts isn't in this diff so I've left it out of the inline set — happy to push it with a regression test alongside the two persistableLeafMeta cases in tool-surface.test.ts if you want it in this PR.

Applying the help-text suggestions

The dor/src/commands/tool.ts and dor/test/snapshots/help/tool.md suggestions are the same sentence and have to be applied together, or cli-output.test.mjs goes red on the snapshot.

[dormouse-bot]

The four earlier findings are addressed and the teardown is safe in both directions — closeAgentBrowserSession and disposeAgentBrowserSurfaceController are no-ops when the tool is iframe-rendered, and a swap back re-creates the controller, whose ensureStarted clears the closedSessions mark for the same deterministic tool.<id> name, so the round-trip isn't poisoned. Two things left, both inline.

The bigger one is that the new tool-trust.test.ts block doesn't pin either half of the fix it names: revert readTextFile's default back to (path) => readFile(path, 'utf-8') and Buffer.byteLength back to text.length, and all three assertions still pass.

[dormouse-bot]

The size-cap tests are load-bearing now — reverting the stat or the Buffer.byteLength turns each of them red, which the previous pair didn't. The pop-out gate is only half in place, though.

The ab-screencast half still offers pop-out

IframePanel is one of two places that register a screen. The other is AgentBrowserSurfaceController's ensureStarted, which registers canPopOut: !!getPlatform().agentBrowserPopOut with no tool gate. A tool declaring render: ab-screencast gets renderMode: 'ab-screencast' written by useToolServing, so BrowserPanel mounts AgentBrowserPanel — and ToolPaneHeader's own header states the consequence: "a tool's browser gets the same URL editor, nav buttons, and Display modal a plain browser Surface has."

So on standalone, pop-out on a serving render: ab-screencast tool is one click, not the two the earlier finding described — and it is destructive rather than inert. onSwapRenderMode's tool branch runs in full: closeAgentBrowserSession(params), disposeAgentBrowserSurfaceController(id), then updateParams writing toolRender: 'ab-screencast' (the mode it was already in) and clearing url / session / wsPort. The browser tears down and useToolServing re-derives it as the same screencast. The user asked for a native window and got a reload.

The controller already receives the surface's params — acquireAgentBrowserSurfaceController(id, { ...params, renderMode: seededMode }) in AgentBrowserPanel — so the same !isToolParams(...) gate fits there, and surfaceType never changes over a surface's life, so seeding it once in the constructor is safe. AgentBrowserSurfaceParams doesn't declare surfaceType, so it needs the field (or an explicit isTool flag) rather than riding the untyped spread.

Happy to push that together with the IframePanel.test.tsx assertion noted inline, if you want them in this PR.

[dormouse-bot]

Both registration sites are gated now, and all four gates are load-bearing — I reverted each one locally and the matching test went red: canPopOut in IframePanel.tsx, canPopOut in AgentBrowserSurfaceController.ensureStarted, the stat in readToolFile, and Buffer.byteLength. The two error-message wordings are distinguishable and only the reachable one is user-facing. tsc -b and the four touched suites pass. Two small things inline.

One note outside the diff: docs/specs/dor-browser.md -> "Display Modal And Render Swaps" still lists ab-popout as "Hidden if the host lacks agentBrowserPopOut", which now reads as the whole gate. dor-tool.md owns the tool rule, so at most a one-line pointer belongs there — but that file is at 4834 of its 4850-word budget, so I've left it as a note rather than a suggestion.

[dormouse-bot]

Autobind is a good call and the refusal-over-tie-break stance matches surface.resolveOpen and the Dev-Server Chip, so the outlier is gone. The settle window is the right shape — the harness regression test earns its place, and listenerUrlsByPort sorting ascending is what makes the element-wise settle comparison deterministic, so it can't fail to converge. Five things inline, one of which is a real gap between the spec sentence and the code.

The one worth reading first: an announcement that arrives after the conflict has been committed never wins. dor-tool.md -> Serving states "An announcement, when present, wins over either" without qualification, and tool-registry.ts's ToolPortMode doc repeats it, but once toolPortConflict is written the tick short-circuits on hasConflict before it ever reads getToolAnnounce. With port: auto on a tool that binds two ports and emits OSC 367 more than ~3s after the second bind (two POLL_MS ticks), the pane sits on the conflict face permanently even though the tool said which port to frame. The lets an announcement override even in auto mode test only pins the early case — it calls recordToolAnnounce before mount — so the late path is unpinned. Details and the two-part fix are inline.

One reuse note that didn't earn an inline suggestion: ToolPaneHeader's canToggle re-derives toolFace's internals (browserUrlFromParams(...) !== null || toolPortConflictFromParams(...) !== null) rather than asking browser-surface.ts, which claims that classification as its own — "so the classification never drifts between them." It can't be toolFace(params) !== 'terminal', because the pinned-terminal case has to stay toggleable, so it wants its own exported predicate (toolHasSecondHalf, say) beside toolFace. Same shape as the isToolParams re-implementation flagged earlier in this PR, just milder: a fourth face would silently not reach the chip.

I could not run the suite — this runner has no pnpm — so the commit message's mutation-testing claims are CI's to confirm, not mine.

[dormouse-bot]

bad8006d landed while I was reading and I reviewed it too: the announcement override is right — the gate now falls through to the announce?.port != null branch and both framing writes clear the stale verdict, which toolFace's conflict-before-url order made necessary. All four open threads from the last pass are addressed.

The upstream key is the right identity and git-remote-url.ts is careful in the ways a security key has to be — lookalike hosts kept apart, userinfo dropped, unparseable input failing closed rather than guessing. The migration that drops v0 denials, and the test that pins the drop, are the right call.

But the headline feature does not work at runtime, and the test suite can't see it.

toolPending is written without cwd, so the pending face never renders

toolPendingFromParams requires five strings — ['name', 'run', 'path', 'projectRoot', 'cwd'] — and the object use-dor-control.ts writes has four: name, run, path, projectRoot, upstreamUrl. No cwd. So the validator returns null for every pending tool the product actually creates.

I replayed the validator against both shapes in node:

production params -> null
test fixture      -> ToolPending

The fixture in ToolPanel.test.tsx hand-writes cwd: '/repo', which is why all five new assertions pass over a shape production never produces. Nothing pins the producer against the consumer — use-dor-control.ts's untrusted branch has no test at all (grep -rn untrusted lib/src --include=*.test.ts finds only host-side hits).

What a user gets today, running dor tool storybook in an unapproved repo:

1. toolPendingFromParams → null, so toolFace falls through to 'terminal'.
2. ToolPanel takes the two-halves path and mounts TerminalPanel → getOrCreateTerminal → spawnPty in the repo's cwd. A shell starts in the unapproved repo — the thing docs/specs/dor-tool.md → Trust now states in bold as impossible ("no PTY is spawned, so not even a shell starts").
3. The approval buttons never render, and resolveToolApproval bails at if (!pending) return;, so there is no way to grant from the pane. dor tool returns pending forever.

Findings are against bad8006d. Three more inline, one of which (--minimize) spawns a PTY in an unapproved repo even after the above is fixed.

How I verified

This runner has no pnpm and no node_modules, so I could not run the suite — the commit message's mutation-testing claims are CI's to confirm, not mine. Finding 1 I checked by copying toolPendingFromParams verbatim into a node script and calling it with the object literal from use-dor-control.ts:818 and the fixture from ToolPanel.test.tsx:124. The rest are read from the merged tree: getOrCreateTerminal at lib/src/lib/terminal-lifecycle.ts (getPlatform().spawnPty on the create path, pendingShellOpts.delete(id) before it), createSplitSurface's if (minimized) { getOrCreateTerminal(newId); … }, and the tool:control case in vscode-ext/src/message-router.ts, which maps a host-side rejection to a resolved { status: 'error' }.

[dormouse-bot]

Three of the five open threads are addressed, and the cwd fix is the right shape — typing the producer's literal as ToolPending is what stops it drifting again. git-remote-url.ts's per-scheme default ports and the settle-memory reset are both correct and their tests are load-bearing (drop the ssh: entry from defaultPorts and the first new case goes red; drop if (!running) seenPorts.current.delete(leaf.id) and the new regression test goes red).

But the approval path still cannot start the tool.

Clearing toolPending before two awaits spawns a bare shell, and the command never runs

resolveToolApproval now writes { toolPending: undefined } first, then awaits the trust op and the re-lookup. That clear is exactly what flips toolFace to 'terminal' — toolPending is checked before everything else in toolFace — so ToolPanel leaves its pending-approval early return and mounts TerminalPanel -> TerminalPane, whose mount effect calls getOrCreateTerminal(id) unconditionally. React flushes that render long before two host round-trips resolve.

getOrCreateTerminal reads pendingShellOpts (empty — deferTerminal staged nothing), spawns a PTY with the default shell and no cwd, and registers the entry. The setPendingShellOpts at the end of resolveToolApproval then lands on an id getOrCreateTerminal will never consult again, because it returns existing first. So clicking Always allow gives a bare shell in the default directory, titled storybook, with the tool's command never typed — the same "the registry entry already existed" failure the commit message describes fixing on the minimize path, relocated into the approval path itself.

The fix is to keep the clear in the same synchronous block as setPendingShellOpts, where bad8006d had it; two inline suggestions do that. The double-grant the current comment guards against is benign either way — both writes are idempotent, and a second setPendingShellOpts before any mount just overwrites the first. If you want a hard guard, a useRef<Set<string>> of in-flight ids is the place for it, not the param write.

Nothing pins this: resolveToolApproval has no test at all, and the five new ToolPanel assertions render the pending face without ever resolving it.

Separately, the comment above the callback still says "The two steps are ordered so a failed write never leaves a running command in an unapproved repo". The order is now trust-then-re-lookup, and it is the resolved?.status !== 'ok' bail that holds the invariant — a failed tool-trust.json write leaves the repo untrusted, so the lookup comes back untrusted and the pane is killed rather than run. Sound guard; the sentence describes the old one.

Three more inline, plus one spec note.

docs/specs/dor-tool.md -> Serving is now behind the code

The settle bullet — "since ports appear one at a time during boot and a framed leaf is never re-scanned" — and the matching rationale paragraph are no longer true: with an announcement present, a framed leaf is now re-scanned on every tick. The new rule (an announcement outranks an already-framed URL, not just a conflict) isn't stated in Serving either; the port field's "an announcement always wins over either" is about auto vs announced, not about re-pointing a live pane. Budget headroom is 46 words.

How I verified

This runner has no pnpm and no node_modules, so the commit message's mutation-testing and pnpm test claims are CI's to confirm, not mine — CI is green at e3be7ef. Everything above is read from the merged tree: toolFace's pending-first ordering in browser-surface.ts, ToolPanel's if (face === 'pending-approval') return <ToolApproval/> early return, TerminalPane's mount effect, and getOrCreateTerminal's const existing = registry.get(id); if (existing) return existing;. The doored-reference reachability is resolveSplitTarget -> resolveListedSurface -> buildDorSurfaceList(), whose own comment says "minimized ones included".

One thing not raised inline: useDorControl's main handler useCallback gained two revealSurface call sites in this PR, but its dependency array lists neither revealSurface nor enterTerminalMode (which revealSurface closes over). nav is listed, so it only goes stale if enterTerminalMode's identity changes without nav's — and there's no react-hooks/exhaustive-deps in the lint config to catch it.

[dormouse-bot]

Nine commits since the last pass, and the two headline fixes both land: resolveToolApproval now stages the shell before clearing toolPending, so the bare-PTY chain is closed, and the trust file is committed under a cross-process lock with the cache dropped — the new serializes concurrent grants test is load-bearing for both halves (remove the lock and the last write wins; restore the cache and the first.isTrusted([upstream]) assertion goes red). The readToolFile rewrite is a real improvement over stat-then-readFile: one descriptor, fstat on it, and a capped read that survives post-fstat growth.

Two things first, both about the environment rather than the code.

The branch conflicts with main (pnpm-lock.yaml), so no CI has run on 2e78b29. CI and Chromatic both went green on e3be7ef; on this head only Cloudflare Pages registered, because GitHub cannot compute the merge ref. That leaves the entire 9-commit increment — ~760 added lines across trust, persistence, and terminal lifecycle — unverified. I could not run the suite either (no pnpm on this runner), so everything below is read from the merged tree.

Five findings, all inline. The first two are the ones worth reading.

--minimize approval stages a command that never spawns

resolveToolApproval ends with setPendingShellOpts(id, …) then if (pending.minimized) minimizePane(id), all in one synchronous block. React never renders between them, so the leaf goes straight from the approval prompt to a Door without ever mounting TerminalPanel — and getOrCreateTerminal is what consumes the staged opts. createSplitSurface has exactly this hazard and handles it explicitly: both its minimize branches call getOrCreateTerminal(newId) before addDoor / minimizePane. The approval path doesn't.

So dor tool storybook --minimize in an unapproved repo shows the prompt (correct — rule 3), the user clicks Always allow, and the pane minimizes into a Door named storybook with no PTY, no command, and nothing running. It only starts if the user happens to reattach it. Nothing pins it: the new Wall.test.tsx approval test passes minimized: false.

Making a tool untouched unguards two destructive paths

untouched: leafMeta?.component === 'tool' is right about what untouched means, but three call sites read it and only one of them is kind-aware:

• createContentSurface — gated: !hasBrowser(reference.kind) && isUntouched(reference.id), and hasBrowser('tool') is true, so a tool is safe here.
• wallActions.onKill — if (isUntouched(id)) killPaneImmediately(id), no gate. A tool serving pnpm storybook that you navigated to but never typed into is untouched (the command is typed through typeCommandWhenPromptReady, which bypasses xterm's onData, so it never marks the Session touched). Clicking the pane's close button kills it outright — the random-char confirm that any hand-started dev server gets is skipped.
• The dormouse:new-terminal handler's shouldReplaceUntouched — detail.replaceUntouched === true && selectedPaneVisible && isUntouched(selectedPaneId!), no gate either. selectShell dispatches with replaceUntouched: true, so picking a different shell while an untouched tool pane is selected runs replaceLeaf(toolId, newId, terminalLeafMeta()) + disposeSession(toolId). The running tool is replaced by a bare shell, and its agent-browser daemon session leaks — useToolServing's retirement branch needs the leaf to still exist to issue the close.

Command-mode navigation selects a pane without touching it, so both are reachable without doing anything unusual. Before this commit untouched: false made all three unreachable for tools. Either gate the two ungated readers on the Surface kind the way createContentSurface does, or keep tools touched and find another way to express "the user hasn't engaged with this yet".

Three smaller ones inline: the pending-reuse reveal didn't get the survivor re-lookup that 2e78b29 just added to the trusted-reuse branch beside it, the trust lock can spin forever on a stale record whose pid was recycled, and O_NOFOLLOW is undefined on Windows so the symlink refusal doesn't exist there.

[dormouse-bot]

Force-pushed since the last pass, so I read 398bba9 fresh; the rebase carried the tool code across unchanged, and the nine commits on top are the five findings from 2e78b29 plus the URL-bar-navigation fix. CI is green at this head (Build & Test, both platform checks, Standalone Smoketest, Webview Boot Smoketest, Chromatic, Cloudflare), so the conflict that left the last increment unverified is gone.

The two headline fixes land. resolveToolApproval now calls getOrCreateTerminal(id) before minimizePane(id), closing the --minimize no-PTY path for the same reason createSplitSurface spawns before addDoor, and the new Wall.test.tsx case is load-bearing for it. appliedAnnouncedPorts is the right shape for the announcement gate — keying "already applied" on the port the poll last acted on rather than on params.url is what lets URL-bar navigation survive, and the retirement branch drops it alongside seenPorts so a re-run re-points from scratch. Resolving the upstream host-side instead of trusting request.upstreamUrl off the wire is the correct boundary, and it degrades to a folder grant — narrower, not wider — when git answers nothing.

Three things, all inline. The first is the one worth reading.

The keyboard kill path was not gated, and two spec sentences now say it was

2e8cfd02 gated wallActions.onKill and shouldReplaceUntouched, which is what the previous review enumerated — but that enumeration was incomplete. handlePaneShortcuts in lib/src/components/wall/keyboard/handle-pane-shortcuts.ts is a fourth reader of isUntouched, and it owns the x/k binding that docs/specs/layout.md names first: if (isUntouched(sid)) { ctx.killPaneImmediately(sid); return; } for a pane, and afterRestore: isUntouched(sid) ? 'kill-immediately' : 'confirm-kill' for a Door. Neither consults the Surface kind, so both hazards the commit describes closing are still open through the keyboard.

Reachable exactly as the commit message describes: command-mode navigation selects a pane without touching it, and a tool's command is typed by typeCommandWhenPromptReady, which calls getPlatform().writePty(id, ...) directly rather than going through xterm's onData, so a tool serving pnpm storybook stays untouched: true for its whole life. Select it, press x, and it dies with no random-char confirm — and for an ab-screencast tool the daemon session leaks, since useToolServing's retirement branch needs the leaf to still exist to issue the close. The click path is pinned by the new requires confirmation before killing an untouched tool test; the keyboard path has no equivalent, and handle-pane-shortcuts.test.ts is where one would go.

ctx.nav.paneParams(sid) is already on WallKeyboardCtx, documented as the surface-type classification seam, so the pane branch gates with one clause. The Door branch has no meta accessor on ctx — either add one, or pass 'confirm-kill' unconditionally for a tool Door, since after restore the leaf is an ordinary pane again. That file is outside this diff, so I have left no suggestion on it; happy to push both gates plus the handle-pane-shortcuts.test.ts cases if you want them in this PR.

[dormouse-bot]

All five open threads are addressed. The keyboard gate is the right shape — ctx.nav.paneParams reads the store, which holds a Door's params too (the sibling handle-mouse-selection-keys.ts already relies on that), so the Door branch needs no new accessor, and both new handle-pane-shortcuts.test.ts cases are load-bearing. isUntouched now has four readers and every one is kind-gated. Dropping upstreamUrl from ToolHostRequest is scoped correctly: the field stays on the response, which is what ToolApproval renders, so only the untrusted inbound direction is gone.

The bakery lock is sound as a mutual-exclusion algorithm — unique participant paths mean no waiter can unlink a pathname a newer owner would reuse, which is the race the last pass flagged; the choosing marker closes the read-max window, and same-ticket ties break on token, so the order is total. merges concurrent grants after reclaiming one aged lock is load-bearing for it (drop the lock and the eight grants collapse to one key), and the orphan-reclaim test still hangs without the pid/mtime reap.

Two things inline. The lock one is the one worth reading.

Two spec sentences the keyboard fix inverted

61b35679 made docs/specs/layout.md -> "Kill confirmation" true, but two quick-reference lines that state the same rule went the other way — both are outside this diff's hunks, so no suggestion on them:

• docs/specs/layout.md, the **x** / **k** (command mode) bullet under Doors: "an untouched Surface is killed outright". That parenthetical describes the exact Door branch this commit changed, and "Surface" is the glossary term that now includes tools. an untouched plain terminal is killed outright matches the section it links to. Budget headroom is 30 words.
• docs/specs/shortcuts.md, the k or x row: "untouched (never-typed-in) panes and doors are killed immediately without the prompt". That file's own header says to keep the table in sync when a binding changes; headroom is 29 words.

Happy to push both plus the two inline fixes if you want them in this PR.

How I verified

This runner has no pnpm, so the commit messages' test claims are CI's to confirm, not mine. pnpm lint:specs I did run (node scripts/spec-lint.mjs → OK), and word counts are wc -w against scripts/spec-word-budgets.json.

The mkdir finding is a direct repro, not a reading: fs.mkdirSync(existingFilePath, { recursive: true }) throws EEXIST on this Node. The rest is read from the merged tree — nav.paneParams as lath.getMeta(id)?.params in Wall.tsx, getMeta as snapshot().leafMeta.get(id) in lath-wall-engine.ts, and use-session-persistence.ts calling lath.getMeta(door.id) as the standing proof that Doored leaves keep their meta.

Two candidates I dropped at verify rather than raising: #hasEarlierParticipant runs #reapIfStale on the caller's own ticket file before the value.token === token self-check, but the same event loop that runs the wait loop runs the heartbeat, so a self-reap needs utimes to fail silently — at which point the holder's lease has collapsed anyway. And the bakery is a lot of machinery for a file written on a human click, but I could not name a simpler primitive that actually fixes the reclaim race, so it is not a finding.

[dormouse-bot]

Reviewing as a draft — flagging what looks worth a quick fix, not a merge verdict. Mark ready for a full review.

Scoped to eee6c217..280a8966. The trust rewrite is the right trade: add-only, idempotent, one file per grant means two hosts never need the bakery lock, and isTrusted validating version/key/kind against the requested key is what keeps the hashed filename from being the authority. The command-run identity in useToolServing closes the exit-and-rerun-within-one-tick hole that command text alone could not see, and the two-pass split keeps a retire from landing on a leaf another leaf's await already decided against. focusSession(id, focused, 'terminal') and the pin's second proof are both pinned by tests that go red when reverted.

One finding.

A failed grant write now leaves the approval prompt with no feedback

resolveToolApproval gates on grant?.status !== 'trust-recorded', and a write failure is a resolved value, not a rejection — vscode-ext/src/message-router.ts's tool:control arm turns a thrown host error into { status: 'error', message: ... }, and VSCodeAdapter.toolControl does the same for a timeout. So when writeJsonAtomic fails (read-only state dir, no space, EPERM on the app data directory), the host's message is discarded and the function returns: the prompt stays exactly as it was, nothing is written to the pane, and the in-flight guard clears so the button is live again and will fail the same silent way on every click.

Before this range the same failure at least closed the pane — the grant was ignored, the follow-up lookup came back untrusted, and closeSurface ran. Retaining the pane is the better behavior and what docs/specs/dor-tool.md → Trust rule 4 now asks for, but it needs to say why it retained.

showShellSpawnNotice is already a dependency of this callback and used four lines below for the restart failure, and it positions over any pane element, so the pending face is a valid target. The suggestion below splits the condition so only the grant failure speaks — !isCurrent() means the Workspace is closing or the pane is gone, which should stay silent.

The grantSucceeds: false case in Wall.test.tsx already drives this path and asserts the leaf survives; it would extend to the notice with one more expectation.

[dormouse-bot]

Reviewing as a draft — flagging what looks worth a quick fix, not a merge verdict. Mark ready for a full review.

Scoped to 8c1257a3. It closes the finding from 280a8966: the grant failure now speaks, !isCurrent() still returns silently so a Surface closed during the host call shows nothing, and both halves are load-bearing on the new assertion — drop the showShellSpawnNotice call and the grantSucceeds: false case loses the text; drop usePaneChrome and it loses it again, because ShellSpawnNotice looks the target up as paneElements.get(notice.id) and the pending face was the one pane body that never registered. My earlier claim that the notice "positions over any pane element, so the pending face is a valid target" was wrong on that second half — the usePaneChrome call is what made it true.

One thing I'd reconsider now that it is wired up.

The notice expires in 1.5 s, and a failed grant is the one case that has to outlive that

showShellSpawnNotice drops itself after 1500 ms. Its other two callers are informational — "Switched to …", "Opened …" — where a flash is the whole point. This one ends in "Try allowing it again", an instruction, on a pane that 1.5 s later is pixel-identical to one nobody has clicked. Nothing distinguishes "never approved" from "approved, and the write failed".

The slowest failures are the ones most likely to go unseen. WorkspaceWindow keeps every Wall mounted in one grid cell and hides the inactive ones with invisible — visibility: hidden, chosen there so a hidden Workspace's reattached xterms keep their box — and ShellSpawnNotice renders inside the Wall's own subtree, so that visibility inherits through its fixed positioning. Click "Always allow for folder" on a host where the write is slow (tool_control in standalone/src-tauri/src/lib.rs gives the op Duration::from_secs(5), and the timeout itself arrives as { status: 'error' }), switch Workspaces while it hangs, and the error paints invisibly in the hidden Wall and expires before you switch back.

Carrying the message on the Surface's params and rendering it in ToolApproval under the buttons — cleared when the next attempt starts — would make the feedback last as long as the condition it reports, which is how rule 4's "visible feedback" reads to me, and it is the shape ToolPortConflict already uses for a state the user has to act on. Keep usePaneChrome either way: the selection ring resolves its target through the same map and bail-and-holds when it is absent (resolvePaneElement(paneElements.get(selectedId)) in WorkspaceSelectionOverlay), so registering the pending face also stopped the ring sticking on the previously selected pane when a pending Tool is selected — and nothing pins that yet.

Unrelated one-liner, outside this diff so I have not touched it: use-pane-chrome.ts describes itself as "used by every panel component (terminal / iframe / agent-browser)", and ToolApproval is now a fourth caller that is not a panel.

[dormouse-bot]

Reviewing as a draft — flagging what looks worth a quick fix, not a merge verdict. Mark ready for a full review.

Scoped to 416b59c7. Carrying the message on toolPending rather than the notice is the right shape, and the identity contract survives it: updateParams shallow-merges, so the cleared object written at the top of the queued callback is the one toolPendingFromParams hands back and isCurrent()'s === pending still holds across the toolControl await. The ring test also pins the usePaneChrome registration I said last pass was unpinned.

Two things on the new error, both inline — one is the approval controls going unreachable, the other is a one-token gap that lets the silent failure back in.

[dormouse-bot]

Reviewing as a draft — flagging what looks worth a quick fix, not a merge verdict. Mark ready for a full review.

Scoped to ea661ad7..fac876e8. The blank-reason fallback is keyed on the right thing and the producers back it up: createToolHost's catch builds error instanceof Error ? error.message : String(error), so an error with an empty message reaches the renderer as '' rather than falling through, and both new it.each cases go red when .trim() is dropped. The centering rewrite is the right mechanism too — my-auto leaves overflow at the scroll origin, which is exactly what justify-center was putting out of reach at both ends.

One thing about where it landed.

The reachability fix forked the shared pane-message ground rather than fixing it

The new root re-types what PANE_MESSAGE_CLASS already holds — bg-terminal-bg px-6 text-center text-sm, plus h-full w-full — minus the centering. Two consequences, and the second is the one that matters.

The constant's own comment in lib/src/components/design.tsx still enumerates its consumers as "the iframe surface's connecting/error states, a tool's port conflict, and a tool awaiting approval". The third is no longer true as of this commit, and that comment is what tells the next editor who they are changing when they touch the ground.

More importantly, the defect the spec rule now forbids lives in the constant, not in ToolApproval. PANE_MESSAGE_CLASS is items-center justify-center with no max-width and no wrap rule, and .lath-host .lath-leaf-body is overflow: hidden, so every consumer clips unreachably in a small pane:

• PanelMessage in IframePanel.tsx composes its base class from PANE_MESSAGE_CLASS plus text-muted. Its resolving state renders "Connecting to <url>…" and its error state renders "For arbitrary web pages, use dor ab open <url>" — an instruction with a URL in it, the same shape as the grant error. A long URL has no break opportunity, so in a narrow pane it overflows sideways and is clipped at both ends: the user can read neither the remedy nor the address it names.
• ToolPortConflict stacks a per-port list plus two explanatory lines; a tool that opened six ports in a short pane loses the tail.

Hoisting is not much more work than what is already here: make PANE_MESSAGE_CLASS the scroll-safe outer (drop items-center justify-center, add overflow-auto) and export the my-auto … self-center inner beside it as a small PaneMessage wrapper, then render all three faces through it. That keeps one definition of the pane-message ground, keeps the comment honest, and fixes the two faces this PR leaves clipping. The spec rule is Tool-scoped and can stay where it is either way.

Separately: nothing pins the new rule. jsdom computes no layout, so Wall.test.tsx can only assert class names, and there is no story for the pending-approval face — the one mechanism here that could hold it is a Storybook story at a narrow pane size, which Chromatic would then guard.

Superseded by the review on a later commit.

[dormouse-bot]

Reviewing as a draft — flagging what looks worth a quick fix, not a merge verdict. Mark ready for a full review.

Scoped to b30c6c38..8e84c6d3. The hoist is clean: the class set on the two divs is byte-for-byte what ToolApproval carried at fac876e8, so the two faces that were clipping pick up the fix without a behavior change to the one that already had it, and ref reaches the scroll root the same way PopupButtonRow takes one (React 19 ref-as-prop, ComponentProps<'div'>), which is what keeps usePaneChrome measuring the right element. All three play assertions are load-bearing — drop [overflow-wrap:anywhere] and the 150-char longPath blows scrollWidth past clientWidth; swap my-auto back for justify-center and the content's top goes above the pane's. modalActionButton sets no whitespace-nowrap, so the long upstream label in Narrow genuinely exercises button wrapping rather than just overflowing.

One thing, inline.

Worth knowing for the ready-for-review pass: .github/workflows/chromatic.yml gates Visual Regression Tests on github.event.pull_request.draft == false, so these three stories — assertions included — have not executed in CI yet. They first run when you mark this ready.

[dormouse-bot]

First pass with the draft flag off, so this is a merge verdict rather than WIP feedback. The trust gate holds where I pushed on it: the dormouse.yml read is bounded and symlink-refusing before any grant check, grant keys are host-derived so the renderer cannot supply one, persistableLeafMeta demotes a pending approval to a plain terminal on both the layout and the Door save path, and the OSC 367 announcement only selects among ports the process-tree scan already found.

Two places where a refusal reaches the user as nothing at all.

A Tool that blocks a Workspace move silently cancels the drag

captureToolParams throws to refuse the move, and that throw propagates out of prepareWorkspaceTransfer through startMove's rethrow — so transferWorkspaceTo and tearOutWorkspace now reject for an ordinary user condition. Every other refusal in that module resolves with { moved: false, reason } instead, and the two callers are built for that contract:

• The strip drag calls it as () => void transferWorkspaceTo(id, hit.label, ...) (in standalone/src/workspace-drag.ts, the move closure built beside the iframes.length > 0 confirm). void on a rejecting promise means the rejection is dropped: drag a Workspace holding an unapproved Tool onto another window and the tab snaps back with no message and nothing in the console. dor workspace move is fine — transferWorkspace in tauri-adapter.ts lets the rejection reach the CLI — so the gap is the gesture most people will use.
• The adopt unwind runs if (handle) (await handle.prepareWorkspaceTransfer()).commit(); inside the adopt_done refused catch in standalone/src/workspace-move.ts. A throw there skips commit(), so the Sessions are never released and the Workspace stays mounted here while Rust has already handed it back — the "live in two windows and persisted by both" state that comment is written against. Narrow (it needs a Tool mid-startup in an arriving Workspace at the moment the watchdog expires), but it is the failure the unwind exists to prevent.

Returning the reason rather than throwing would let both call sites keep the contract they already implement. Happy to push that if you'd like — it's a captureToolParams signature change plus the prepareWorkspaceTransfer caller, and it is not obvious to me whether you'd rather refuse at prepareWorkspaceTransfer or one level up in startMove.

Re-resolution failure closes the approval pane with no explanation

Inline below.