diff --git a/crates/biorouter/src/providers/coding_agent/bridge.rs b/crates/biorouter/src/providers/coding_agent/bridge.rs
index 8ae34f5d..b0ae9b03 100644
--- a/crates/biorouter/src/providers/coding_agent/bridge.rs
+++ b/crates/biorouter/src/providers/coding_agent/bridge.rs
@@ -705,10 +705,18 @@ impl BridgeGrant {
         let request = UserActionRequest::ToolApproval(ToolApprovalRequest {
             tool_name: call.name.to_string(),
             arguments: arguments.clone(),
-            prompt: Some(format!(
-                "{} asked to run this through Biorouter.",
-                self.child_label()
-            )),
+            // ⚠ **`prompt` is the inspector's field — "why you are being asked" —
+            // and nothing else may borrow it.** This used to carry "<child> asked
+            // to run this through Biorouter", which is framing, not a finding; the
+            // card reads any prompt as a SECURITY FINDING, so every bridged call
+            // arrived under a warning banner with "Always Allow" withheld. The
+            // card was telling the truth about the field it was given.
+            //
+            // The attribution belongs on the card, but it needs a field of its
+            // own (`requestedBy`) plumbed through `ActionRequiredData` and the
+            // OpenAPI client. Until then it is logged rather than dressed up as
+            // an inspector's verdict.
+            prompt: None,
             risk: Some(self.tool_risks.risk_for(&call.name)),
             preview: crate::conversation::tool_preview::ToolPreview::for_tool_call(
                 &call.name, &arguments,
@@ -729,15 +737,19 @@ impl BridgeGrant {
             UserActionOutcome::Approved { permission } => {
                 tracing::info!(
                     tool_name = %name,
+                    child = self.child_label(),
                     ?permission,
                     "a bridged tool call was approved by the user"
                 );
+                self.record_lasting_decision(&call.name, &permission).await;
                 Ok(())
             }
             // `AlwaysDeny` and `DenyOnce` read the same to the child: it may not
             // run this. The *scope* of the refusal is the permission store's
-            // business, not the child's.
-            UserActionOutcome::Denied { .. } => {
+            // business, not the child's — which is why the store is written
+            // before the refusal is worded.
+            UserActionOutcome::Denied { permission } => {
+                self.record_lasting_decision(&call.name, &permission).await;
                 Err(format!("`{name}` was refused: you did not approve it."))
             }
             other => Err(format!(
@@ -749,6 +761,37 @@ impl BridgeGrant {
         }
     }
 
+    /// Write a decision the user meant to LAST into the permission store.
+    ///
+    /// The outcome's `permission` carries the scope of the answer — its own doc
+    /// says it "distinguishes a one-off from an `AlwaysAllow` the caller may want
+    /// to record" — and on the agent's own path `handle_approved_and_denied_tools`
+    /// records it. The bridge only logged it, so "Always Allow" on a bridged card
+    /// granted a single call and the next identical one asked again: a card
+    /// offering a lasting decision it could not keep. An existing entry was
+    /// always honoured (the permission inspector reads the store before the card
+    /// is ever raised); what was missing was writing one.
+    ///
+    /// A one-off (`AllowOnce` / `DenyOnce`) is deliberately not recorded: that is
+    /// an answer about this call, not a rule.
+    async fn record_lasting_decision(
+        &self,
+        tool_name: &str,
+        permission: &crate::permission::Permission,
+    ) {
+        use crate::config::permission::PermissionLevel;
+        use crate::permission::Permission;
+
+        let level = match permission {
+            Permission::AlwaysAllow => PermissionLevel::AlwaysAllow,
+            Permission::AlwaysDeny => PermissionLevel::NeverAllow,
+            _ => return,
+        };
+        self.inspections
+            .update_permission_manager(tool_name, level)
+            .await;
+    }
+
     /// What to call the child on the approval card.
     ///
     /// The user is being asked to approve a call *they* did not make, so the card
diff --git a/ui/desktop/src/components/MessageCopyLink.test.tsx b/ui/desktop/src/components/MessageCopyLink.test.tsx
new file mode 100644
index 00000000..9df90a2d
--- /dev/null
+++ b/ui/desktop/src/components/MessageCopyLink.test.tsx
@@ -0,0 +1,83 @@
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { describe, expect, it, vi, beforeEach, afterEach } from 'vitest';
+
+const mocks = vi.hoisted(() => ({ toastError: vi.fn() }));
+vi.mock('../toasts', () => ({ toastError: mocks.toastError }));
+
+import MessageCopyLink from './MessageCopyLink';
+
+/** No rich node, so the component takes the plain-text path. */
+const noContent = { current: null };
+
+/**
+ * ⚠ **Call this AFTER `userEvent.setup()`.** `setup()` installs a clipboard stub
+ * of its own, so a stub written first is replaced by one whose `writeText`
+ * resolves — and every failure test quietly measures a success.
+ */
+function stubClipboard(writeText: () => Promise<void>) {
+  // `Object.assign` works once and then trips over the prototype getter, which
+  // makes the second test in the file fail for a reason that has nothing to do
+  // with what it is testing.
+  Object.defineProperty(navigator, 'clipboard', {
+    value: { writeText: vi.fn(writeText), write: vi.fn() },
+    configurable: true,
+    writable: true,
+  });
+}
+
+beforeEach(() => {
+  mocks.toastError.mockClear();
+  // The app's own logging stays quiet; these paths log on purpose.
+  vi.spyOn(console, 'error').mockImplementation(() => {});
+});
+
+afterEach(() => vi.restoreAllMocks());
+
+/**
+ * The reported defect: when both clipboard writes fail, the outer catch logged
+ * `'Failed to copy text: '`, the inner catch logged `'Failed to copy text
+ * (fallback): '`, and that was the end of it. `markCopied()` was never reached,
+ * so the button went on saying "Copy" — the user's only way to learn nothing had
+ * been copied was to paste somewhere and find out.
+ */
+describe('MessageCopyLink', () => {
+  it('says so when the clipboard refuses', async () => {
+    const user = userEvent.setup();
+    stubClipboard(() => Promise.reject(new Error('denied')));
+    render(<MessageCopyLink text="hello" contentRef={noContent} />);
+
+    await user.click(screen.getByRole('button', { name: 'Copy message' }));
+
+    await waitFor(() => expect(screen.getByRole('button')).toHaveTextContent('Copy failed'));
+    expect(mocks.toastError).toHaveBeenCalledTimes(1);
+    expect(mocks.toastError.mock.calls[0][0]).toMatchObject({ title: 'Copy failed' });
+  });
+
+  it('leaves the success path alone', async () => {
+    const user = userEvent.setup();
+    stubClipboard(() => Promise.resolve());
+    render(<MessageCopyLink text="hello" contentRef={noContent} />);
+
+    await user.click(screen.getByRole('button', { name: 'Copy message' }));
+
+    await waitFor(() => expect(screen.getByRole('button')).toHaveTextContent('Copied!'));
+    expect(mocks.toastError).not.toHaveBeenCalled();
+  });
+
+  it('still counts a successful fallback as a copy', async () => {
+    // The rich write is what fails here — jsdom has no `ClipboardItem`, which is
+    // the same shape of failure as a browser refusing the `text/html` flavour —
+    // and the plain-text retry succeeds.
+    const user = userEvent.setup();
+    stubClipboard(() => Promise.resolve());
+    const contentRef = { current: document.createElement('div') };
+    contentRef.current.textContent = 'hello';
+    render(<MessageCopyLink text="hello" contentRef={contentRef} />);
+
+    await user.click(screen.getByRole('button', { name: 'Copy message' }));
+
+    await waitFor(() => expect(screen.getByRole('button')).toHaveTextContent('Copied!'));
+    expect(mocks.toastError).not.toHaveBeenCalled();
+  });
+});
diff --git a/ui/desktop/src/components/MessageCopyLink.tsx b/ui/desktop/src/components/MessageCopyLink.tsx
index 8d36eb8e..1bce6f43 100644
--- a/ui/desktop/src/components/MessageCopyLink.tsx
+++ b/ui/desktop/src/components/MessageCopyLink.tsx
@@ -1,15 +1,21 @@
 import React from 'react';
-import { Copy } from './icons/app-icons';
+import { AlertTriangle, Copy } from './icons/app-icons';
 import { MessageMetaAction } from './MessageMeta';
-import { useTransientFlag } from '../hooks/useTransientFlag';
+import { useTransientValue } from '../hooks/useTransientFlag';
+import { toastError } from '../toasts';
 
 interface MessageCopyLinkProps {
   text: string;
   contentRef: React.RefObject<HTMLDivElement | null>;
 }
 
+/** What the clipboard write is asked to put on the clipboard. */
+type CopyOutcome = 'copied' | 'failed';
+
 export default function MessageCopyLink({ text, contentRef }: MessageCopyLinkProps) {
-  const [copied, markCopied] = useTransientFlag(2000);
+  // One transient state with two values rather than two booleans that could
+  // both be true: the button says exactly one thing at a time.
+  const [outcome, markOutcome] = useTransientValue<CopyOutcome>(2000);
 
   const handleCopy = async () => {
     try {
@@ -32,22 +38,43 @@ export default function MessageCopyLink({ text, contentRef }: MessageCopyLinkPro
         await navigator.clipboard.writeText(text);
       }
 
-      markCopied();
+      markOutcome('copied');
+      return;
     } catch (err) {
       console.error('Failed to copy text: ', err);
-      // Fallback to plain text if HTML copy fails
-      try {
-        await navigator.clipboard.writeText(text);
-        markCopied();
-      } catch (fallbackErr) {
-        console.error('Failed to copy text (fallback): ', fallbackErr);
-      }
     }
+
+    // Fallback to plain text if the rich copy failed.
+    try {
+      await navigator.clipboard.writeText(text);
+      markOutcome('copied');
+      return;
+    } catch (fallbackErr) {
+      console.error('Failed to copy text (fallback): ', fallbackErr);
+    }
+
+    // ⚠ Both writes failed, and this is the branch that used to end at a
+    // `console.error` the user cannot see: `markCopied()` was never reached, so
+    // the button went on saying "Copy" and the only way to find out nothing had
+    // been copied was to paste. Say so, in both places the user might be
+    // looking — on the control they pressed, and once in the corner.
+    markOutcome('failed');
+    toastError({
+      title: 'Copy failed',
+      msg: 'Biorouter could not write to the clipboard. Select the message and copy it with your keyboard.',
+    });
   };
 
+  const failed = outcome === 'failed';
+
   return (
-    <MessageMetaAction onClick={handleCopy} icon={<Copy />} aria-label="Copy message">
-      {copied ? 'Copied!' : 'Copy'}
+    <MessageMetaAction
+      onClick={handleCopy}
+      icon={failed ? <AlertTriangle /> : <Copy />}
+      aria-label="Copy message"
+      className={failed ? 'text-text-warning hover:text-text-warning' : undefined}
+    >
+      {outcome === 'copied' ? 'Copied!' : failed ? 'Copy failed' : 'Copy'}
     </MessageMetaAction>
   );
 }
diff --git a/ui/desktop/src/components/ToolCallConfirmation.test.tsx b/ui/desktop/src/components/ToolCallConfirmation.test.tsx
index 682b4ffe..cb13ff97 100644
--- a/ui/desktop/src/components/ToolCallConfirmation.test.tsx
+++ b/ui/desktop/src/components/ToolCallConfirmation.test.tsx
@@ -334,6 +334,42 @@ describe('ToolCallConfirmation (BR-63)', () => {
     expect(screen.queryByRole('button', { name: /Always Allow/i })).not.toBeInTheDocument();
     expect(screen.getByRole('button', { name: /Deny/i })).toBeInTheDocument();
   });
+
+  /**
+   * The other half of the same rule, and the one that was wrong in practice.
+   *
+   * `prompt` is `approval_prompt_for_request` — an inspector's reason for
+   * escalating — so a card with none is an ordinary permission ask and the user
+   * may grant a lasting permission from it. The coding-agent bridge used to fill
+   * that field with its own framing ("<child> asked to run this through
+   * Biorouter"), so every bridged call arrived under a warning banner with
+   * "Always Allow" withheld: a security verdict the daemon never reached.
+   * `bridge.rs` no longer writes it, and `bridgeApprovalPrompt.test.ts` keeps it
+   * that way.
+   */
+  it('offers "Always Allow" for an ordinary ask, with no warning banner', () => {
+    renderCard({
+      prompt: null,
+      preview: { kind: 'shell', command: 'ls -la', truncated: false },
+    });
+
+    expect(screen.getByRole('button', { name: /Always Allow/i })).toBeInTheDocument();
+    expect(screen.queryByTestId('tool-security-finding')).not.toBeInTheDocument();
+  });
+
+  /**
+   * A blank prompt is not a finding. A daemon sending `" "` — or a future
+   * producer trimming a message to nothing — used to paint an empty warning band
+   * AND take the user's "Always Allow" away, which is the worst of both: a
+   * warning that says nothing, and a permission that cannot be granted because
+   * of it.
+   */
+  it('treats a blank prompt as no finding at all', () => {
+    renderCard({ prompt: '   ' });
+
+    expect(screen.getByRole('button', { name: /Always Allow/i })).toBeInTheDocument();
+    expect(screen.queryByTestId('tool-security-finding')).not.toBeInTheDocument();
+  });
 });
 
 /**
diff --git a/ui/desktop/src/components/ToolCallConfirmation.tsx b/ui/desktop/src/components/ToolCallConfirmation.tsx
index 38f66686..39aaf0bb 100644
--- a/ui/desktop/src/components/ToolCallConfirmation.tsx
+++ b/ui/desktop/src/components/ToolCallConfirmation.tsx
@@ -190,6 +190,34 @@ export default function ToolConfirmation({
     return parts.length > 1 ? parts[0] : '';
   }
 
+  // `prompt` is `approval_prompt_for_request` — every reason an INSPECTOR gave
+  // for escalating this call — so its presence is what marks a security finding.
+  //
+  // One derived boolean rather than two independent reads of `prompt`: the
+  // warning banner and the withheld "Always Allow" are two halves of one
+  // decision, and a card that shows the banner while still offering a permanent
+  // grant (or the reverse) is worse than either. Whitespace is not a finding —
+  // a blank prompt used to paint an empty warning band *and* take the user's
+  // "Always Allow" away.
+  //
+  // ⚠ The coding-agent bridge used to put its own framing there ("<child> asked
+  // to run this through Biorouter"), which put every bridged call behind a
+  // warning banner with no way to grant a lasting permission. The card was
+  // reading the field correctly; the producer was misusing it. Fixed in
+  // `bridge.rs::await_approval` and pinned by `bridgeApprovalPrompt.test.ts`.
+  //
+  // ⚠ That guard covers `bridge.rs` and ONLY `bridge.rs` — it string-matches that
+  // one file. Do NOT read it as "nothing but an inspector writes `prompt`": five
+  // other production sites still put framing there, so their cards still draw the
+  // banner and still withhold "Always Allow" —
+  // `extension_manager_extension.rs` (install, delete), `platform_approval.rs`,
+  // `skills_extension.rs` and `bug_report/mod.rs`. Withholding the grant is
+  // arguably wanted for the destructive ones (they carry `requires_user_proof`),
+  // but the *banner* is not: one of them reads "install … from the trusted BAAM
+  // registry" under a warning triangle. Closing that needs a field distinct from
+  // `prompt`, which is a protocol change, so it is a known gap rather than a fix.
+  const securityFinding = typeof prompt === 'string' && prompt.trim().length > 0;
+
   // One cohesive, bordered "permission request" card. A single border wraps the
   // whole element (header + actions) so there are no mismatched borders, it uses
   // the app's standard card tokens + typography, and a gentle slide-in makes it
@@ -201,9 +229,12 @@ export default function ToolConfirmation({
   ) : (
     <>
       <div className="biorouter-message-content text-body overflow-hidden rounded-2xl border border-border-subtle bg-background-default animate-in fade-in slide-in-from-bottom-1 duration-200">
-        {/* Security finding banner, only when the backend flagged one */}
-        {prompt && (
-          <div className="flex items-start gap-2 border-b border-border-subtle bg-background-warning/10 px-4 py-2.5 text-sm text-text-warning">
+        {/* Security finding banner, only when an inspector flagged one */}
+        {securityFinding && (
+          <div
+            data-testid="tool-security-finding"
+            className="flex items-start gap-2 border-b border-border-subtle bg-background-warning/10 px-4 py-2.5 text-sm text-text-warning"
+          >
             <AlertTriangle className="mt-0.5 h-4 w-4 shrink-0" />
             <span>{prompt}</span>
           </div>
@@ -280,8 +311,10 @@ export default function ToolConfirmation({
                 >
                   Allow Once
                 </Button>
-                {/* Only offer "Always Allow" when there's no security finding. */}
-                {!prompt && (
+                {/* Only offer "Always Allow" when there's no security finding. A
+                    permanent grant is not something to decide from a card that
+                    exists because an inspector objected. */}
+                {!securityFinding && (
                   <Button
                     type="button"
                     size="sm"
diff --git a/ui/desktop/src/components/bridgeApprovalPrompt.test.ts b/ui/desktop/src/components/bridgeApprovalPrompt.test.ts
new file mode 100644
index 00000000..91120b37
--- /dev/null
+++ b/ui/desktop/src/components/bridgeApprovalPrompt.test.ts
@@ -0,0 +1,73 @@
+import { readFileSync } from 'node:fs';
+import { dirname, resolve } from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { describe, expect, it } from 'vitest';
+
+/**
+ * The producer half of the approval card's one rule, asserted from the consumer's
+ * side because this is where the consequence shows up.
+ *
+ * `ToolCallConfirmation` reads a card's `prompt` as a SECURITY FINDING: it paints
+ * a warning banner and withholds "Always Allow", on the grounds that a permanent
+ * grant is not a thing to decide from a card that exists because an inspector
+ * objected. That is only sound while `prompt` carries nothing but
+ * `approval_prompt_for_request` — the inspectors' own reasons.
+ *
+ * The coding-agent bridge broke it: every bridged call parked a card whose prompt
+ * was the bridge's own framing ("<child> asked to run this through Biorouter"), so
+ * every one of them arrived under a security banner, with no way to grant a
+ * lasting permission, for a verdict no inspector had reached.
+ *
+ * A TypeScript test reaching into Rust is deliberate. The rule spans the two
+ * languages, the renderer half is pinned next door in
+ * `ToolCallConfirmation.test.tsx`, and a rule that is only checked on one side of
+ * a boundary is how this drifted in the first place. (`autovis_cdn_desktop_contract.rs`
+ * does the same thing in the other direction.)
+ */
+const here = dirname(fileURLToPath(import.meta.url));
+const BRIDGE = resolve(
+  here,
+  '../../../..',
+  'crates/biorouter/src/providers/coding_agent/bridge.rs'
+);
+
+const bridge = readFileSync(BRIDGE, 'utf-8');
+
+/** The body of one `fn` in the bridge, up to the next item at the same depth. */
+function functionBody(name: string): string {
+  const start = bridge.indexOf(`async fn ${name}(`);
+  expect(start, `${name} should exist in bridge.rs`).toBeGreaterThan(-1);
+  const rest = bridge.slice(start + 1);
+  const end = rest.search(/\n {4}(?:pub )?(?:async )?fn |\n {4}\/\/\/ /);
+  return end === -1 ? rest : rest.slice(0, end);
+}
+
+describe('the bridge and the approval card agree on what `prompt` means', () => {
+  const awaitApproval = functionBody('await_approval');
+
+  it('parks its card without inventing a security finding', () => {
+    expect(awaitApproval).toContain('prompt: None');
+    expect(awaitApproval).not.toMatch(/prompt:\s*Some\(/);
+  });
+
+  it('does not dress its own framing up as an inspector verdict', () => {
+    // The attribution is worth showing the user — it just needs a field of its
+    // own rather than the one that means "an inspector objected".
+    expect(bridge).not.toContain('asked to run this through Biorouter');
+  });
+
+  it('records an approval the user meant to last, so the card is not lying', () => {
+    // Offering "Always Allow" is only honest if the answer survives the turn.
+    // `handle_approved_and_denied_tools` does this on the agent's own path; the
+    // bridge only logged the permission, so the next identical call asked again.
+    const calls = awaitApproval.match(/record_lasting_decision/g) ?? [];
+    expect(calls.length, 'both the approved and the denied arm must record').toBe(2);
+
+    const record = functionBody('record_lasting_decision');
+    expect(record).toContain('Permission::AlwaysAllow => PermissionLevel::AlwaysAllow');
+    expect(record).toContain('Permission::AlwaysDeny => PermissionLevel::NeverAllow');
+    expect(record).toContain('update_permission_manager');
+    // A one-off is an answer about this call, not a rule.
+    expect(record).toMatch(/_ => return/);
+  });
+});
diff --git a/ui/desktop/src/components/sessions/SessionListView.test.tsx b/ui/desktop/src/components/sessions/SessionListView.test.tsx
index a4f9b59e..44975800 100644
--- a/ui/desktop/src/components/sessions/SessionListView.test.tsx
+++ b/ui/desktop/src/components/sessions/SessionListView.test.tsx
@@ -713,10 +713,13 @@ describe('SessionListView subagent toggle', () => {
     );
 
     const input = await screen.findByLabelText(/show subagent runs/i);
-    // `sr-only` is what hands the painting to the app's own box. A revert to the
-    // native control fails here, and the label association below keeps the
-    // accessible control from being replaced by a decorative div.
-    expect(input).toHaveClass('sr-only');
+    // `appearance-none opacity-0` is what hands the painting to the app's own
+    // box. A revert to the native control fails here, and the label association
+    // below keeps the accessible control from being replaced by a decorative div.
+    // (It read `sr-only` until the primitive stopped hiding its input in a 1px
+    // corner — see `Checkbox.tsx`: that shape made the visible square a picture
+    // unless a call site remembered to wrap it in a label.)
+    expect(input).toHaveClass('appearance-none', 'opacity-0');
     expect(input).toHaveAttribute('type', 'checkbox');
 
     fireEvent.click(input);
diff --git a/ui/desktop/src/components/settings/app/AppSettingsSection.test.tsx b/ui/desktop/src/components/settings/app/AppSettingsSection.test.tsx
new file mode 100644
index 00000000..e69c1b15
--- /dev/null
+++ b/ui/desktop/src/components/settings/app/AppSettingsSection.test.tsx
@@ -0,0 +1,61 @@
+import { describe, expect, it, vi, beforeEach } from 'vitest';
+import { render, screen } from '@testing-library/react';
+
+// The Appearance rows are what this file is about; the rest of the App tab is
+// other sections' business and pulls in the API client, the theme registry and
+// the usage panel.
+vi.mock('./UpdateSection', () => ({ default: () => null }));
+vi.mock('../usage/UsageSection', () => ({ default: () => null }));
+vi.mock('./ResetPanel', () => ({ default: () => null }));
+vi.mock('../../BioRouterSidebar/ThemeSelector', () => ({ default: () => null }));
+vi.mock('../../BioRouterSidebar/ThemeFamilySelector', () => ({ default: () => null }));
+
+import AppSettingsSection from './AppSettingsSection';
+
+beforeEach(() => {
+  Object.assign(window, {
+    electron: {
+      platform: 'darwin',
+      getMenuBarIconState: vi.fn().mockResolvedValue(true),
+      getDockIconState: vi.fn().mockResolvedValue(true),
+      getWakelockState: vi.fn().mockResolvedValue(true),
+      setMenuBarIcon: vi.fn().mockResolvedValue(true),
+      setDockIcon: vi.fn().mockResolvedValue(true),
+      setWakelock: vi.fn().mockResolvedValue(true),
+      openNotificationsSettings: vi.fn(),
+    },
+    appConfig: { get: vi.fn().mockReturnValue(undefined) },
+  });
+});
+
+/**
+ * Measured with the accessibility tree: all four Appearance switches came back
+ * with `aria-label` null, `aria-labelledby` null and no text content, so a
+ * screen reader announced "switch, on" with no subject — four times in one
+ * panel, each about something different.
+ *
+ * The subject is on screen; it is the `<p>` beside the switch. It just was not
+ * connected to the control, which is exactly what the Privacy tiers switch two
+ * panels over does connect (`aria-label="Privacy tiers"`), and this follows it.
+ *
+ * The name is the visible label verbatim, not a paraphrase: someone driving the
+ * app by voice says what they can read.
+ */
+describe('Appearance switches', () => {
+  it.each([['Menu bar icon'], ['Dock icon'], ['Prevent sleep'], ['Cost tracking']])(
+    'announces what "%s" is about',
+    async (name) => {
+      render(<AppSettingsSection />);
+      expect(await screen.findByRole('switch', { name })).toHaveAccessibleName(name);
+    }
+  );
+
+  it('names every switch in the panel, so none is left to be found by position', async () => {
+    render(<AppSettingsSection />);
+    await screen.findByRole('switch', { name: 'Menu bar icon' });
+    const unnamed = screen
+      .getAllByRole('switch')
+      .filter((control) => !control.getAttribute('aria-label')?.trim());
+    expect(unnamed).toEqual([]);
+  });
+});
diff --git a/ui/desktop/src/components/settings/app/AppSettingsSection.tsx b/ui/desktop/src/components/settings/app/AppSettingsSection.tsx
index d53d9e76..23f0ecb8 100644
--- a/ui/desktop/src/components/settings/app/AppSettingsSection.tsx
+++ b/ui/desktop/src/components/settings/app/AppSettingsSection.tsx
@@ -179,6 +179,7 @@ export default function AppSettingsSection({ scrollToSection }: AppSettingsSecti
               checked={menuBarIconEnabled}
               onCheckedChange={handleMenuBarIconToggle}
               variant="mono"
+              aria-label="Menu bar icon"
             />
           </div>
 
@@ -195,6 +196,7 @@ export default function AppSettingsSection({ scrollToSection }: AppSettingsSecti
                 checked={dockIconEnabled}
                 onCheckedChange={handleDockIconToggle}
                 variant="mono"
+                aria-label="Dock icon"
               />
             </div>
           )}
@@ -210,6 +212,7 @@ export default function AppSettingsSection({ scrollToSection }: AppSettingsSecti
               checked={wakelockEnabled}
               onCheckedChange={handleWakelockToggle}
               variant="mono"
+              aria-label="Prevent sleep"
             />
           </div>
 
@@ -225,6 +228,7 @@ export default function AppSettingsSection({ scrollToSection }: AppSettingsSecti
                 checked={showPricing}
                 onCheckedChange={handleShowPricingToggle}
                 variant="mono"
+                aria-label="Cost tracking"
               />
             </div>
           )}
diff --git a/ui/desktop/src/components/ui/AppTooltipLayer.test.tsx b/ui/desktop/src/components/ui/AppTooltipLayer.test.tsx
index c1b9ce02..44522340 100644
--- a/ui/desktop/src/components/ui/AppTooltipLayer.test.tsx
+++ b/ui/desktop/src/components/ui/AppTooltipLayer.test.tsx
@@ -108,6 +108,34 @@ describe('AppTooltipLayer', () => {
     expect(tooltip).toHaveClass('w-max', 'max-w-[min(20rem,calc(100vw-16px))]', 'break-words');
   });
 
+  /**
+   * The stranded tooltip. Hover a row control, then change route without moving
+   * the pointer: the target unmounts, so no `pointerout` is ever delivered and
+   * the tooltip is left on screen describing an element that no longer exists.
+   *
+   * The check for this was `useEffect(…, [tooltip])` — it ran when the tooltip
+   * STATE changed, which is never the case here.
+   */
+  it('dismisses a tooltip whose target leaves the page', async () => {
+    const { rerender } = render(
+      <>
+        <AppTooltipLayer />
+        <NativeTitleTarget title="Native action" />
+      </>
+    );
+
+    const target = screen.getByTestId('native-title-target');
+    await waitFor(() => expect(target).toHaveAttribute('data-biorouter-tooltip', 'Native action'));
+    fireEvent.pointerOver(target);
+    expect(await screen.findByRole('tooltip')).toHaveTextContent('Native action');
+
+    // The route change. The pointer never moves, so the only signal is the
+    // removal itself.
+    rerender(<AppTooltipLayer />);
+
+    await waitFor(() => expect(screen.queryByRole('tooltip')).toBeNull());
+  });
+
   it('does not open after the pointer leaves during the delay', async () => {
     render(
       <>
diff --git a/ui/desktop/src/components/ui/AppTooltipLayer.tsx b/ui/desktop/src/components/ui/AppTooltipLayer.tsx
index 6626b219..e1118d04 100644
--- a/ui/desktop/src/components/ui/AppTooltipLayer.tsx
+++ b/ui/desktop/src/components/ui/AppTooltipLayer.tsx
@@ -196,9 +196,32 @@ export function AppTooltipLayer() {
     }
   }, [horizontalShift, tooltip]);
 
+  // A tooltip outlives its target when the target LEAVES rather than when the
+  // pointer does: hover a row control, change route without moving the pointer,
+  // and no `pointerout` is ever delivered — the element the pointer was over is
+  // simply gone, and the tooltip stays on screen describing nothing.
+  //
+  // ⚠ This used to be `useEffect(… , [tooltip])`, which is a check that runs
+  // only when the tooltip STATE changes — never for the one case it was written
+  // for. Adding `tooltip.target` to the deps does not fix it either: a node
+  // reference does not change when the node is removed. The removal is a DOM
+  // event, so it takes a DOM observer.
+  const tooltipTarget = tooltip?.target ?? null;
   useEffect(() => {
-    if (tooltip && !tooltip.target.isConnected) setTooltip(null);
-  }, [tooltip]);
+    if (!tooltipTarget) return;
+    if (!tooltipTarget.isConnected) {
+      setTooltip(null);
+      return;
+    }
+    const dismissWhenTargetLeaves = () => {
+      if (!tooltipTarget.isConnected) setTooltip(null);
+    };
+    // Only while a tooltip is open, and only an `isConnected` read per batch —
+    // the observer is torn down the moment the tooltip closes.
+    const observer = new MutationObserver(dismissWhenTargetLeaves);
+    observer.observe(document.body, { childList: true, subtree: true });
+    return () => observer.disconnect();
+  }, [tooltipTarget]);
 
   if (!tooltip) return null;
 
diff --git a/ui/desktop/src/components/ui/Checkbox.test.tsx b/ui/desktop/src/components/ui/Checkbox.test.tsx
index 5d919751..c352370c 100644
--- a/ui/desktop/src/components/ui/Checkbox.test.tsx
+++ b/ui/desktop/src/components/ui/Checkbox.test.tsx
@@ -19,12 +19,57 @@ describe('Checkbox', () => {
     expect(input).toHaveAttribute('type', 'checkbox');
     // Not `hidden`, not a div with a role: the native control stays in the tree
     // and in the tab order, so keyboard, form participation and the label
-    // association all keep working. `sr-only` is only what stops the OS drawing
-    // a second, un-themeable box on top of ours.
-    expect(input).toHaveClass('sr-only');
+    // association all keep working. `appearance-none` + `opacity-0` is what
+    // stops the OS drawing a second, un-themeable box on top of ours.
+    expect(input).toHaveClass('appearance-none', 'opacity-0');
     expect((input as HTMLInputElement).checked).toBe(true);
   });
 
+  /**
+   * The measured defect (2026-09-11): the input was `peer sr-only`, a 1px
+   * clipped box in the corner, so the 22px square everyone can see was a
+   * picture. `ResetPanel`'s category boxes toggled on nothing at all and
+   * `ExportAppDialog`'s toggled only on their text — the label sat *beside* the
+   * box, not around it — while `SessionListView`'s worked only because a
+   * `<label>` wraps it. A primitive whose correctness depends on every call site
+   * remembering a wrapper is the bug; this is the contract that ends it.
+   *
+   * ⚠ Asserted at the source. jsdom computes no layout and routes a click to the
+   * element the test names, so it cannot answer "does a click at the centre of
+   * the square reach the input?" whatever the CSS says. That was measured in
+   * Chromium instead (unchecked before, checked after); what is pinned here is
+   * the geometry the browser needs in order to route it.
+   */
+  it('makes the input itself the hit target, so no call site has to wrap it', () => {
+    render(<Checkbox aria-label="Include the vault" />);
+    const input = screen.getByLabelText('Include the vault');
+
+    // Stretched over the whole 24px target, on top of the paint...
+    expect(input).toHaveClass('absolute', 'inset-0', 'h-full', 'w-full');
+    // ...and not tucked away where only a keyboard or a label can reach it.
+    expect(input).not.toHaveClass('sr-only');
+
+    // Every painted sibling has to stay out of the way, or the topmost of them
+    // swallows the click the input is there to receive.
+    const painted = Array.from(input.parentElement?.children ?? []).filter(
+      (child) => child !== input
+    );
+    expect(painted.length).toBeGreaterThan(0);
+    for (const child of painted) expect(child).toHaveClass('pointer-events-none');
+  });
+
+  /**
+   * Keyboard focus was invisible whichever way the input was hidden: the global
+   * `input[type='checkbox']:focus-visible` rule in `main.css` answers focus with
+   * `outline: none` and a background colour, and the input is transparent. The
+   * indication has to live on the square that is actually painted.
+   */
+  it('puts the focus ring on the square the user can see', () => {
+    render(<Checkbox aria-label="Include the vault" />);
+    const box = screen.getByLabelText('Include the vault').nextElementSibling;
+    expect(box).toHaveClass('peer-focus-visible:ring-2', 'peer-focus-visible:ring-border-focus');
+  });
+
   it('writes the indeterminate state, which has no HTML attribute', () => {
     // React cannot set this declaratively — it is a DOM property only, so a
     // missing effect would leave a tri-state control silently stuck on
diff --git a/ui/desktop/src/components/ui/Checkbox.tsx b/ui/desktop/src/components/ui/Checkbox.tsx
index 68986fb0..38a09236 100644
--- a/ui/desktop/src/components/ui/Checkbox.tsx
+++ b/ui/desktop/src/components/ui/Checkbox.tsx
@@ -11,12 +11,34 @@ import { cn } from '../../utils';
  * under a page title. The OS control has no idea the app has themes, and no
  * amount of surrounding styling can reach inside it.
  *
- * Built exactly like {@link CustomRadio}, its sibling in the same spec section:
- * a `peer sr-only` native input driving styled siblings. That keeps every native
- * behaviour — keyboard, focus, form participation, the label's `htmlFor`
- * association, indeterminate state — without adding a Radix package for one
- * control, and it is why the ring and the tick can both respond to
- * `peer-checked`.
+ * Built like {@link CustomRadio}, its sibling in the same spec section: a `peer`
+ * native input driving styled siblings. That keeps every native behaviour —
+ * keyboard, focus, form participation, the label's `htmlFor` association,
+ * indeterminate state — without adding a Radix package for one control, and it
+ * is why the ring and the tick can both respond to `peer-checked`.
+ *
+ * ⚠ **The input is the hit target, not an `sr-only` sliver.** It used to be
+ * `peer sr-only` — a 1px clipped box in the corner — which made the 22px square
+ * everybody can see a picture rather than a control: the only way to toggle it
+ * was the keyboard, or a `<label>` that a call site had to remember to provide.
+ * Two shipped screens did not (measured 2026-09-11: `ResetPanel`'s per-category
+ * boxes toggled on nothing at all, and `ExportAppDialog`'s toggled only on their
+ * text, because the label sat beside the box rather than around it).
+ *
+ * So the fix is here rather than at the call sites: an `appearance-none
+ * opacity-0` input stretched over the whole 24px target. It is the topmost
+ * thing in the box and every sibling is `pointer-events-none`, so a click
+ * anywhere on the square lands on the real input. `appearance-none` plus
+ * `opacity-0` is what keeps the OS from drawing its own un-themeable box on top
+ * of ours — the reason the original reached for `sr-only`. Wrapping it in a
+ * `<label>` still works exactly as before: the browser does not forward a label
+ * activation whose target is already the labelled control, so there is no
+ * double toggle.
+ *
+ * The visible square also carries the focus ring now. The global
+ * `input[type='checkbox']:focus-visible` rule in `main.css` paints a background
+ * and removes the outline, which on a transparent input is no indication at all,
+ * so keyboard focus was invisible whichever way the input was hidden.
  *
  * Geometry is the radio's, so a checkbox and a radio stacked in one list agree
  * on their optical axis: a 22px visual box inside a 24px hit target. The outer
@@ -62,7 +84,10 @@ export const Checkbox = React.forwardRef<HTMLInputElement, CheckboxProps>(
             else if (forwardedRef) forwardedRef.current = node;
           }}
           disabled={disabled}
-          className={cn('peer sr-only', !disabled && 'cursor-pointer')}
+          className={cn(
+            'peer absolute inset-0 m-0 h-full w-full appearance-none opacity-0',
+            !disabled && 'cursor-pointer'
+          )}
           {...props}
         />
         {/* `--border-emphasized` is the interactive-border token (§3.2) — ink at
@@ -72,7 +97,8 @@ export const Checkbox = React.forwardRef<HTMLInputElement, CheckboxProps>(
           className="pointer-events-none absolute inset-[1px] rounded-inner border-[1.5px] border-border-emphasized
                      transition-colors
                      peer-checked:border-border-accent peer-checked:bg-background-accent
-                     peer-indeterminate:border-border-accent peer-indeterminate:bg-background-accent"
+                     peer-indeterminate:border-border-accent peer-indeterminate:bg-background-accent
+                     peer-focus-visible:ring-2 peer-focus-visible:ring-border-focus"
         />
         {/* The mark is `--text-on-accent`, not `white`: that is the one token
             whose contract is "legible on the accent fill", which is exactly the
diff --git a/ui/desktop/src/components/ui/dialog.tsx b/ui/desktop/src/components/ui/dialog.tsx
index c6c3b94c..a75d4794 100644
--- a/ui/desktop/src/components/ui/dialog.tsx
+++ b/ui/desktop/src/components/ui/dialog.tsx
@@ -5,6 +5,7 @@ import * as DialogPrimitive from '@radix-ui/react-dialog';
 import { XIcon } from '../icons/app-icons';
 
 import { cn } from '../../utils';
+import { installDialogTabRepair } from './dialogTabRepair';
 
 function Dialog({ ...props }: React.ComponentProps<typeof DialogPrimitive.Root>) {
   return <DialogPrimitive.Root data-slot="dialog" {...props} />;
@@ -45,15 +46,47 @@ function DialogContent({
   showCloseButton = dismissible,
   onEscapeKeyDown,
   onPointerDownOutside,
+  ref,
   ...props
 }: React.ComponentProps<typeof DialogPrimitive.Content> & {
   dismissible?: boolean;
   showCloseButton?: boolean;
 }) {
+  // See `dialogTabRepair`: a `Select` unmounting its live region on blur makes
+  // Radix's focus scope swallow the Tab that was moving off it, which left the
+  // New schedule dialog's Cancel and "Create schedule" keyboard-unreachable.
+  // The repair belongs here, on the one primitive every modal composes, because
+  // the trigger is any `Select` (or anything else that mutates the dialog's DOM
+  // while blurring) rather than anything the schedule dialog does.
+  const attachRepair = React.useCallback(
+    (node: HTMLDivElement | null) => {
+      const forward = (value: HTMLDivElement | null) => {
+        if (typeof ref === 'function') ref(value);
+        else if (ref) (ref as React.RefObject<HTMLDivElement | null>).current = value;
+      };
+      forward(node);
+      if (!node) return;
+      const teardown = installDialogTabRepair(node);
+      // React 19 calls a ref callback's cleanup INSTEAD of re-invoking it with
+      // `null`, so the forwarded ref has to be cleared here or a caller holding
+      // one would keep a detached node.
+      return () => {
+        teardown();
+        forward(null);
+      };
+    },
+    [ref]
+  );
+
   return (
     <DialogPortal data-slot="dialog-portal">
       <DialogOverlay />
       <DialogPrimitive.Content
+        ref={attachRepair}
+        // Radix does not set this itself — it isolates the rest of the page with
+        // `aria-hidden` instead — so a screen reader was told this was a dialog
+        // but never that it was a modal one.
+        aria-modal="true"
         data-slot="dialog-content"
         className={cn(
           // No radius utility here on purpose: `.biorouter-modal-surface` (main.css,
diff --git a/ui/desktop/src/components/ui/dialogTabRepair.test.tsx b/ui/desktop/src/components/ui/dialogTabRepair.test.tsx
new file mode 100644
index 00000000..6542ff4b
--- /dev/null
+++ b/ui/desktop/src/components/ui/dialogTabRepair.test.tsx
@@ -0,0 +1,114 @@
+import { render, screen, fireEvent } from '@testing-library/react';
+import { describe, expect, it } from 'vitest';
+import { Dialog, DialogContent, DialogTitle } from './dialog';
+
+/**
+ * The measured defect (Chromium, the **New schedule** dialog): twelve Tab
+ * presses cycled Name → Browse → "Repeat every" → the dialog container, and
+ * Cancel, "Create schedule", the × and the three time selects were never
+ * focused.
+ *
+ * ⚠ **jsdom cannot reproduce the cause, and `userEvent.tab()` passes on the
+ * unfixed code** — it computes the next focusable and focuses it directly, so
+ * the window this bug lives in (the moment between `focusout` and `focusin`,
+ * when `document.activeElement` is `<body>` and a `MutationObserver` microtask
+ * gets to run) never opens. It was measured with Playwright against the real
+ * component; what is pinned here is the *pattern* that window leaves behind — a
+ * `focusout` that named its destination, immediately followed by the dialog
+ * container taking focus instead — and the two cases the repair must not touch.
+ */
+function renderDialog() {
+  render(
+    <Dialog open>
+      <DialogContent aria-describedby={undefined}>
+        <DialogTitle>Schedule</DialogTitle>
+        <button type="button">First</button>
+        <button type="button">Second</button>
+      </DialogContent>
+    </Dialog>
+  );
+  return {
+    container: screen.getByRole('dialog'),
+    first: screen.getByRole('button', { name: 'First' }),
+    second: screen.getByRole('button', { name: 'Second' }),
+  };
+}
+
+/** The restore is deferred past the park loop, so a check has to be too. */
+const settle = () => Promise.resolve();
+
+/**
+ * The three steps the browser really performs, in order: the control blurs, the
+ * browser reports where the Tab was headed, and — in the window where nothing is
+ * focused — Radix parks focus on the dialog. `blur()` first is what makes the
+ * park realistic: it is only because focus is on `<body>` that `container.focus()`
+ * raises no `focusout` of its own.
+ */
+function parkFocusOnDialog(
+  container: HTMLElement,
+  from: HTMLElement,
+  headedFor: HTMLElement | null
+) {
+  from.blur();
+  fireEvent.focusOut(from, { relatedTarget: headedFor });
+  container.focus();
+}
+
+describe('dialog Tab repair', () => {
+  it('hands focus back to the control the Tab was going to', async () => {
+    const { container, first, second } = renderDialog();
+    first.focus();
+
+    parkFocusOnDialog(container, first, second);
+    await settle();
+
+    expect(document.activeElement).toBe(second);
+  });
+
+  it('answers a park that repeats, which is how the real one arrives', async () => {
+    const { container, first, second } = renderDialog();
+    first.focus();
+
+    // Radix parks once per mutation record, and react-select's blur produces
+    // four. A repair that restored inside the first park's `focusin` would be
+    // overwritten by the rest and the user would still land on the dialog.
+    parkFocusOnDialog(container, first, second);
+    container.focus();
+    container.focus();
+    await settle();
+
+    expect(document.activeElement).toBe(second);
+  });
+
+  it('leaves the park alone when the focused control really was removed', async () => {
+    const { container, first } = renderDialog();
+    first.focus();
+
+    // A genuine removal drops focus to the document, so the browser has no
+    // destination to report. Radix's park is the right answer here.
+    parkFocusOnDialog(container, first, null);
+    await settle();
+
+    expect(document.activeElement).toBe(container);
+  });
+
+  it('does not chase a destination from an earlier task', async () => {
+    const { container, first, second } = renderDialog();
+    first.focus();
+    first.blur();
+    fireEvent.focusOut(first, { relatedTarget: second });
+
+    // The Tab finished long ago; the dialog is focused later for its own
+    // reasons — a click on its chrome, say.
+    await new Promise((resolve) => setTimeout(resolve, 0));
+    container.focus();
+    await settle();
+
+    expect(document.activeElement).toBe(container);
+  });
+
+  it('tells a screen reader the dialog is modal', () => {
+    const { container } = renderDialog();
+    expect(container).toHaveAttribute('aria-modal', 'true');
+  });
+});
diff --git a/ui/desktop/src/components/ui/dialogTabRepair.ts b/ui/desktop/src/components/ui/dialogTabRepair.ts
new file mode 100644
index 00000000..c6a9d8fb
--- /dev/null
+++ b/ui/desktop/src/components/ui/dialogTabRepair.ts
@@ -0,0 +1,139 @@
+/**
+ * Put back a Tab that the dialog's own focus trap cancelled.
+ *
+ * ## The bug this exists for
+ *
+ * Measured in Chromium on the **New schedule** dialog: twelve Tab presses
+ * visited only Name → Browse → "Repeat every" → the dialog container, over and
+ * over. Cancel, "Create schedule", the × and the three time selects were never
+ * focused. The trap itself was fine — the actions were simply never reached.
+ *
+ * The mechanism is an interaction between two libraries, and neither is wrong on
+ * its own:
+ *
+ * 1. `react-select` renders its `aria-live` announcements as children that exist
+ *    only while the control is focused (`isFocused && <ScreenReaderText/>`).
+ *    Blur unmounts those four `<span>`s **synchronously**, inside the `focusout`
+ *    dispatch, because React flushes discrete events without batching.
+ * 2. Radix's `FocusScope` watches the dialog subtree with a `MutationObserver`
+ *    to catch "the focused element was removed, so the browser dropped focus on
+ *    `<body>`" — and answers it by focusing the dialog container.
+ *
+ * Between a `focusout` and the matching `focusin`, `document.activeElement` is
+ * `<body>`, and the JS stack empties — so the observer's microtask runs *inside*
+ * that window, sees removals with focus apparently on `<body>`, and parks focus
+ * on the container. The Tab the browser was in the middle of delivering is lost,
+ * and every control after the first `Select` in the dialog becomes unreachable.
+ *
+ * This is not specific to the schedule dialog: any dialog holding a `Select`
+ * (the model picker, the provider modals, lead/worker settings) has it, which is
+ * why the repair lives on the dialog primitive rather than in `CronPicker`.
+ *
+ * ## The repair
+ *
+ * The browser told us where the Tab was going — `focusout.relatedTarget`. If the
+ * dialog container then takes focus itself, that is the park above, and focus is
+ * handed back to the element the browser had chosen.
+ *
+ * Three details are load-bearing, and each was measured rather than reasoned:
+ *
+ * - **The restore is deferred to a microtask.** Radix's observer parks focus
+ *   *once per mutation record* — react-select's blur produces four — so a
+ *   restore performed inside the first park's `focusin` is simply overwritten by
+ *   the next three. Deferring puts it after the whole loop, where it sticks; a
+ *   later observer batch then sees a focused control and stands down by itself.
+ * - **Landing on the intended control does not end the episode**, and neither
+ *   does blurring *towards the container*. Both happen while the park and the
+ *   browser's own transfer interleave, and treating either as "focus moved, we
+ *   are done" makes the repair a no-op for exactly the sequence it exists for.
+ * - **A genuine removal is left alone.** When the focused element really is
+ *   removed, the blur carries no `relatedTarget` — focus fell to the document —
+ *   so nothing is remembered and Radix's park stands, which is what it is for.
+ *
+ * The intent is dropped at the end of the task, so a container focus arriving
+ * later — a click on dialog chrome, say — can never be answered with a stale
+ * target.
+ */
+
+/** How many times one Tab may be put back before the repair gives up. */
+const MAX_RESTORES_PER_EPISODE = 3;
+
+/**
+ * Watch `container` for the cancelled-Tab pattern and undo it.
+ *
+ * Returns the teardown. Safe to call with any element; it touches nothing until
+ * focus moves.
+ */
+export function installDialogTabRepair(container: HTMLElement): () => void {
+  let intended: HTMLElement | null = null;
+  let forgetTimer: ReturnType<typeof setTimeout> | null = null;
+  let restorePending = false;
+  let restores = 0;
+
+  const forget = () => {
+    intended = null;
+    restores = 0;
+    if (forgetTimer !== null) {
+      clearTimeout(forgetTimer);
+      forgetTimer = null;
+    }
+  };
+
+  const scheduleRestore = () => {
+    if (!intended || restorePending) return;
+    restorePending = true;
+    queueMicrotask(() => {
+      restorePending = false;
+      const target = intended;
+      if (!target) return;
+      // Something other than the park won the race; whatever it was, it is a
+      // better answer than a focus we inferred.
+      if (document.activeElement !== container) return;
+      if (!target.isConnected || !container.contains(target)) {
+        forget();
+        return;
+      }
+      // A cap, not a rhythm: an endless volley is a bug, not something a user
+      // should have to sit through.
+      if (restores >= MAX_RESTORES_PER_EPISODE) {
+        forget();
+        return;
+      }
+      restores += 1;
+      target.focus();
+    });
+  };
+
+  const handleFocusOut = (event: FocusEvent) => {
+    const next = event.relatedTarget;
+    // The park taking focus back mid-episode. Keep the destination: answering it
+    // is the whole job.
+    if (next === container && intended) return;
+    if (!(next instanceof HTMLElement) || next === container || !container.contains(next)) {
+      forget();
+      return;
+    }
+    intended = next;
+    if (forgetTimer === null) forgetTimer = setTimeout(forget, 0);
+  };
+
+  const handleFocusIn = (event: FocusEvent) => {
+    if (event.target !== container) {
+      if (event.target !== intended) forget();
+      return;
+    }
+    // The dialog itself has focus. Nothing in the app focuses the container
+    // deliberately except Radix — on open, when there is no destination
+    // remembered, and on the park this undoes.
+    scheduleRestore();
+  };
+
+  container.addEventListener('focusout', handleFocusOut);
+  container.addEventListener('focusin', handleFocusIn);
+
+  return () => {
+    forget();
+    container.removeEventListener('focusout', handleFocusOut);
+    container.removeEventListener('focusin', handleFocusIn);
+  };
+}