vscode extension: "Timeout waiting for server to start" with CLI 2.0.10 (stdout marker mismatch + missing server auth)

Bug report: VS Code extension (sst-dev.opencode-v2) incompatible with CLI v2.0.10

Summary

The VS Code extension sst-dev.opencode-v2 v0.1.1 (latest on the marketplace, no newer pre-release) cannot open its panel when used with CLI v2.0.10: it fails with Failed to open OpenCode panel: Timeout waiting for server to start after 15000ms. There are two independent incompatibilities between the extension and the current opencode serve output/behavior.

Environment

• opencode version: 2.0.10 (channel: latest)
• Extension: sst-dev.opencode-v2 v0.1.1 (latest published)
• OS: Linux Vostro-15 7.0.0-31-generic #31~24.04.1-Ubuntu x86_64
• Terminal: TERM_PROGRAM=vscode, TERM=xterm-256color, COLORTERM=truecolor
• Shell: /bin/bash
• Install/channel: latest
• Active plugins: none found in config

Reproduction

1. Install opencode CLI v2.0.10 and the sst-dev.opencode-v2 extension (v0.1.1) in VS Code.
2. Open any workspace and run the "OpenCode: Open OpenCode Assistant" command (or click the panel).
3. The extension spawns opencode serve --hostname=127.0.0.1 --port=4096 and waits for a stdout marker.
4. After 15s: Failed to open OpenCode panel: Timeout waiting for server to start after 15000ms.

Expected Behavior

The extension's spawn helper should detect that the server is listening and the panel should connect to it.

Actual Behavior

Issue 1 — stdout marker mismatch (causes the reported timeout).
opencode serve in v2.0.10 prints:

server listening on http://127.0.0.1:4096
server password <random>

but the extension's bundled spawn helper waits for a line that starts with opencode server listening:

for (let o of lines)
  if (o.startsWith("opencode server listening")) { /* parse url */ }

The marker never matches, so the promise rejects after the 15s timeout even though the server is up and serving (log shows GET / → 401 from the spawned process while the extension is still waiting).

Issue 2 — server requires Basic auth, extension never sends credentials.
opencode serve (v2.0.10) enforces HTTP Basic auth on all endpoints, with a random password printed on stdout when OPENCODE_SERVER_PASSWORD is unset:

$ opencode serve --hostname 127.0.0.1 --port 4455
server listening on http://127.0.0.1:4455
server password zNAK...

$ curl -w '%{http_code}\n' http://127.0.0.1:4455/api/info
HTTP 401
$ curl -u opencode:<password> -w '%{http_code}\n' http://127.0.0.1:4455/api/info
HTTP 200

The extension never sends an Authorization header — not via the bundled SDK client, nor in its raw fetch calls (/health, /app/providers, /config/providers, and the SSE event stream). So even if issue 1 is fixed, every request would return 401.

Setting OPENCODE_SERVER_PASSWORD="" does not disable auth (the server still generates a random password), so there is no config-side workaround from inside the extension.

Additional Context

• The old sst-dev.opencode (v1-era) extension is equally broken with the v2 CLI (it runs opencode --port N, an unrecognized flag in v2).
• Local workaround I applied to make the panel usable (for reference):
  1. accept the new server listening marker in the spawn helper;
  2. inject a fixed OPENCODE_SERVER_PASSWORD into the spawned server env;
  3. wrap globalThis.fetch in the extension host to attach Authorization: Basic base64(opencode:<password>) to localhost requests.
     With those three changes the panel works against v2.0.10.
• Reproducibility: consistent, 100% of attempts on this machine.
• Related prior issues: #18714 (old extension --port flag), #24737 (401 between plugin and server).

---

Diagnosis generated with the OpenCode report skill; reproduction output collected on 2026-09-19.

Locate the VS Code extension's bundled spawn helper, SDK client, and raw fetch calls for /health, /app/providers, /config/providers, and the SSE stream. First reproduce the 15-second timeout with opencode serve --hostname=127.0.0.1 --port=4096, then compare its server listening and password output with the extension's parsing and request handling. Done means the panel starts and authenticated requests succeed against CLI v2.0.10.