[BUG] VSCode extension silently fails when OPENCODE_SERVER_PASSWORD is set in env #38084

Description

When the user has OPENCODE_SERVER_USERNAME / OPENCODE_SERVER_PASSWORD exported in their shell/profile (a common setup for opencode serve / remote sharing, as suggested in the docs), the official VSCode extension (sdks/vscode) silently breaks:

• openTerminal polls GET /app to detect server readiness (src/extension.ts:78). With the env vars set, the server enables Basic Auth and returns 401, so the poll never succeeds.
• After 10 retries connected = false and appendPrompt is skipped (src/extension.ts:87).
• appendPrompt itself would also POST /tui/append-prompt without credentials (src/extension.ts:94) → 401.
• Net effect: the "Add filepath to terminal" command silently no-ops. No error is shown to the user.

Root cause: terminal.sendText(`opencode --port ${port}`) inherits the VSCode process env, so the spawned server turns auth on; the extension's fetch calls never send an Authorization header. /app and /tui/append-prompt are not in PUBLIC_UI_PATHS (packages/opencode/src/server/shared/public-ui.ts), so they are protected.

Plugins

N/A (official sdks/vscode extension)

OpenCode version

1.18.4

Steps to reproduce

1. export OPENCODE_SERVER_PASSWORD=secret (and optionally OPENCODE_SERVER_USERNAME=opencode) in the shell that launches VSCode, or in a profile sourced by it.
2. Open a workspace in VSCode with the official opencode extension installed.
3. Run the opencode.openTerminal command (or open a file and trigger opencode.addFilepathToTerminal).
4. Observe: terminal starts opencode --port <port>, but the filepath prompt is never appended. Server returns 401 for /app and /tui/append-prompt.

Reproduction with curl (server started with opencode --port):

Screenshot and/or share link

N/A

Operating System

Ubuntu 22.04 (reproduced locally)

Terminal

VSCode integrated terminal

Related issues: #8173, #8676, #9706, #9066, #16096, #18611 — same root cause (env-inherited OPENCODE_SERVER_PASSWORD + client missing Authorization header), but all cover the TUI / Desktop / opencode run / opencode attach / plugin client paths. PR #9095 unified the fix across packages/opencode (tui/attach.ts, tui/thread.ts, tui/worker.ts, flag/auth.ts, plugin/index.ts) but did not touch sdks/vscode/src/extension.ts. git log -- sdks/vscode/src/extension.ts shows no auth-related changes since the extension was written.

We are willing to open a PR for this. Two candidate fix directions (happy to take maintainer guidance on which is preferred):

• A. Strip the auth env vars from the spawned terminal — in vscode.window.createTerminal({ env }), explicitly clear OPENCODE_SERVER_USERNAME / OPENCODE_SERVER_PASSWORD so the local server stays unsecured for the extension's own fetches. Simple, but loses the ability to let users deliberately password-protect the extension-spawned server.
• B. Make the extension's fetch send Basic auth — read the inherited env vars and add Authorization: Basic … to both fetches, mirroring what PR fix(TUI): complete auth fix for TUI with server password (HTTP mode) #9095 did for the TUI worker via getAuthorizationHeader(). More consistent with the existing cross-package fix and works if the user intentionally sets the password.

Either way the extension should also surface a visible error instead of silently skipping appendPrompt after the /app poll fails.