Fix secret storage persistence in VS Code Server web

[mutl3y]

Fixes #317329

Problem

When using VS Code Server (server-linux-x64-web) accessed via a browser, the secretStorageProvider is set to undefined when remoteAuthority is set and the vscode-secret-key-path cookie is absent. This causes all secrets (GitHub auth tokens, Copilot credentials, etc.) to be stored in-memory only — lost on every page refresh or folder switch.

The CLI (code serve-web) already implements the full mint-key protocol in cli/src/commands/serve_web.rs. The Node.js server binary never did.

Root cause

workbench.ts (lines 609-621) already has the correct logic:

const secretStorageCrypto = secretStorageKeyPath && ServerKeyedAESCrypto.supported()
    ? new ServerKeyedAESCrypto(secretStorageKeyPath) : new TransparentCrypto();

    ? undefined
    : new LocalStorageSecretStorageProvider(secretStorageCrypto),

It uses ServerKeyedAESCrypto (AES-256, keys survive page reload) when vscode-secret-key-path is set, falling back to TransparentCrypto otherwise. But the server never set that cookie, so the browser always fell back to in-memory storage.

Fix

Implement the same mint-key protocol in webClientServer.ts that the CLI already implements in Rust:

1. Persistent server key — on first start, a random 32-byte server secret is generated and written to ${userDataPath}/serve-web-key-half (mode 0600). It is reloaded on every subsequent start so server restarts / VS Code updates do not invalidate stored secrets.

2. Client key cookie — every root-page response sets vscode-cli-secret-half (HttpOnly, SameSite=Strict, Max-Age=30 days) carrying the client's 32-byte key half.

3. Path cookie — every root-page response also sets vscode-secret-key-path pointing to /_vscode-server/mint-key, telling the workbench where to fetch the server's contribution.

4. Mint endpoint — POST /_vscode-server/mint-key returns SHA-256(serverKey || clientKeyHalf)[0:32] as application/octet-stream. The browser XORs this with its local half to produce the AES-256 key for ServerKeyedAESCrypto.

This is a direct port of get_server_key_half, get_client_key_half, handle_secret_mint, and append_secret_headers from cli/src/commands/serve_web.rs. The derivation, cookie names, and file name (serve-web-key-half) are identical.

Note: The mint path is /_vscode-server/mint-key (vs the CLI's _vscode-cli/mint-key) to avoid collision if both servers ever run on the same origin. workbench.ts reads the path from the cookie so this is transparent to the browser.

Changes

• src/vs/server/node/webClientServer.ts — implement mint protocol (the only file changed)
• src/vs/code/browser/workbench/workbench.ts — reverted to upstream; no changes needed

Testing

Verified with a Playwright end-to-end test against a running server-linux-x64-web instance (via an external mint-proxy that implements the same protocol):

• Both secret cookies are set on page load
• POST /_vscode-server/mint-key returns 32 bytes
• Workbench loads with title containing "Visual Studio Code"
• WebSocket connects successfully via wss://
• No console errors

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@deepak1556

Matched files:

• src/vs/code/browser/workbench/workbench.ts

[Copilot]

Pull request overview

This PR fixes loss of GitHub/Copilot authentication state in VS Code Server web by ensuring the web workbench always provides a persisted secretStorageProvider (backed by browser localStorage) instead of falling back to the in-memory secret storage implementation when remoteAuthority is set and the vscode-secret-key-path cookie is missing.

Changes:

• Always instantiate LocalStorageSecretStorageProvider for secret storage in the web workbench (removes the remote+no-cookie special case).
• As a result, secrets persist across page refreshes and workspace/folder switches in server-web scenarios.

[mutl3y]

@copilot apply changes based on this feedback

[mutl3y]

@microsoft-github-policy-service agree

[aeschli]

@connor4312 Maybe you are more familiar with this...