Managed voice in VS Code

[nedtwigg]

A Hosted VS Code build now offers managed voice, as the standalone app does: Settings → Notifications enables it by its own Hosted approval, and alarms speak in the member's ElevenLabs voice. The Marketplace is the main install channel.

• Storage: createManagedVoiceHost takes a settings store. Standalone keeps managed-voice.json; VS Code keeps the token and the chosen voice in SecretStorage, each under its own key.
• Windows: every VS Code window runs its own voice host, with its own clip cache and "no plan" state. An approval runs in the window that asked; the token it saves, a voice choice, or a Disconnect reaches every other window, which re-reads SecretStorage on each change. A re-read waits behind any save in progress, so a stale save can't put a token back after Disconnect.
• Failure cases across windows: a re-read never re-arms a token this window's failed Disconnect left in the store, and a 401 forgets only the token it refused, never one a sibling saved before this window re-read.
• Network policy: the window running the Burrow service asks it before every speak and approval request. Other windows read the saved policy, and a failed read counts as Nothing.
• Shared webview code: the webview half of the voice port moved into lib, so Tauri, the dev harness and VS Code use the same code. The extension tells the webview at startup whether the build is Hosted.
• CSP: the VS Code webview now allows media-src blob:.
• Specs: vscode.md has a new "Managed voice" section. alert.md (the 401 rule), transport.md, security-local, security-remote (self-host builds never get the voice flag) and remote-network are updated.

To check

• Autoplay of an alarm nobody clicked, in VS Code's webview, is unverified. If it is refused, the alarm falls back to the system voice.
• The chosen voice is in SecretStorage although it isn't secret. It is the only store whose changes every window hears.

Test plan

• All package suites; typechecks for lib, standalone and vscode-ext; spec and md lints
• A real alarm in VS Code with two windows open, against a Hosted preview

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	1c14f42
Status:	✅  Deploy successful!
Preview URL:	https://dfb459d8.mouseterm.pages.dev
Branch Preview URL:	https://vscode-managed-voice.mouseterm.pages.dev

View logs

[dormouse-bot]

A 401 in one window can delete a token another window has just saved. In request, the 401 branch's generation === tokenGeneration guard works when there is a single process, because setToken bumps the generation synchronously. Across VS Code windows, a sign-in reaches a sibling only after its secrets.onDidChange → invalidate runs. The race goes like this:

1. The user removes the computer at the account page, which revokes T1 with its Burrow (relay-api.ts, "revoked with it").
2. They sign in again from the broker window, which stores T2.
3. Window B still has a speak with T1 in flight. It gets the 401 before its invalidate runs, so it sees the old generation and calls setToken(null).
4. secretManagedVoiceStore.write then runs secrets.delete on the token key without checking what is there, which removes T2 in every window.

The sign-in is silently undone. The window is narrow and the user can recover by signing in again, but it is the reverse of the race the PR body says is closed ("a stale save can't put a token back after sign-out").

A compare-before-clear would close it without adding anything new. On the 401 path, inside serialize, drop loaded, re-read the store, and clear only if the stored token still equals the config.token that was sent. That turns the 401 into "forget this token" rather than "forget whatever is stored".

[dormouse-bot]

The extraction left a stale JSDoc block behind. /** A changed token forgets every clip and every refusal the old one earned. */ used to describe setToken. It now sits directly above clearToken's own doc comment, and the new setToken comment repeats it. Editors attach only the nearest block, so the line is dead text that misdescribes clearToken to anyone reading the source.