Desktop: orange dot (server not connected) after 1.18.23 — bundled serve returns 401 Basic Auth #45596

Desktop shows orange dot after upgrade to 1.18.23 — bundled serve returns 401

Summary

After OpenCode Desktop auto-updated to 1.18.23 via ShipIt, the server status indicator (top-bar dot) stays orange ("not connected") instead of green. The bundled opencode serve is running on an ephemeral port but returns HTTP 401 Unauthorized with WWW-Authenticate: Basic realm="Secure Area". The Electron Renderer cannot authenticate, so the UI never reaches "connected" state.

Environment

• Desktop.app: 1.18.23 (mtime 2026-08-25, auto-updated via ShipIt)
• CLI binary: ~/.opencode/bin/opencode 1.18.9 (was, before manual upgrade) → 1.18.23 after my upgrade
• OS: macOS 15.x (Apple Silicon)
• External CLI serve: 127.0.0.1:4096 runs fine, returns 200 — confirms CLI binary works, the 401 is desktop-only
• Desktop bundled serve: ephemeral port (e.g. 127.0.0.1:51434, 58781, 58487 — different on each launch), returns 401 on every endpoint including /, /global/health, /random/path

How to reproduce

1. Auto-update OpenCode Desktop to 1.18.23 (or fresh install on macOS)
2. Launch Desktop
3. Observe top-bar dot is orange instead of green
4. From terminal: curl -v http://127.0.0.1:<ephemeral>/global/health — see HTTP 401

Diagnostic evidence

$ curl -sI http://127.0.0.1:51434/global/health
HTTP/1.1 401 Unauthorized
www-authenticate: Basic realm="Secure Area"
vary: Origin
...

$ curl -sI http://127.0.0.1:4096/global/health   # external CLI serve, fine
HTTP/1.1 200 OK

# 5041 (NodeService Helper) lsof listener on 127.0.0.1:51434 (changes per launch)
# Renderer (PID 5043) gets 401 when calling it — same loop in every crash dump

Crashpad dump (Electron minidump, 880KB) preserved at ~/Library/Application Support/ai.opencode.desktop/Crashpad/pending/ between crashes — contains v8-oom-last-os-error string. The NodeService Helper repeatedly crashes and is auto-restarted by ShipIt (~6 crashes in 90 minutes) while the orange dot persists.

Root cause hypothesis

Looking at the bundled opencode JS (from app.asar strings + same code in ~/.opencode/bin/opencode):

const password = credentials?.password ?? Flag.OPENCODE_SERVER_PASSWORD;
const username = credentials?.username ?? Flag.OPENCODE_SERVER_USERNAME ?? "opencode";
// ...
let pwd = opts?.password ?? process.env.OPENCODE_SERVER_PASSWORD;
if (!pwd) return;  // skip Basic Auth
return `Basic ${Buffer.from(`${opts?.username ?? process.env.OPENCODE_SERVER_USERNAME}`).toString("base64")}`;

The Basic Auth check returns early when OPENCODE_SERVER_PASSWORD is unset. With it set, the serve requires auth on every request — but the Renderer doesn't have the matching credentials, hence 401 → orange dot.

launchctl getenv OPENCODE_SERVER_PASSWORD returns empty for me, but ps eww on the desktop process shows OPENCODE_CLIENT=desktop, OPENCODE_DISABLE_EMBEDDED_WEB_UI=true, etc. — implying the desktop's startup code may programmatically set OPENCODE_SERVER_PASSWORD as part of its sandboxing/isolation model (matching the 12-opencode-serve.md known-issue note about launchctl-injected vars in CLI serve). After 1.18.22 → 1.18.23, the Renderer-side credential sync appears broken in some setups (mine included).

Workarounds I tried (none worked)

• Cleaned ~/Library/Application Support/ai.opencode.desktop/Crashpad/pending/*.dmp (avoid crash loop)
• Quitted and relaunched Desktop (osascript -e 'tell application "OpenCode" to quit')
• Both 4096 and 4097 CLI serves verified healthy ({healthy:true, version:"1.18.23"})
• Restart produces a fresh ephemeral port each time — always 401

Suspected break

Comparing 1.18.22 → 1.18.23 release notes (if any), possibly a change in:

• How the Renderer learns the serve URL/credentials (was previously a known IPC channel)
• Or how OPENCODE_SERVER_PASSWORD is propagated to the Helper process but not the Renderer

Reproduction confirmed on

• macOS Darwin 25.6.0 (Apple Silicon)
• Desktop.app CFBundleVersion 1.18.23
• Crashpad dump pending before cleanup (now empty): 142cc15d-9075-430a-adb6-644ee60b27ea.dmp

Suggestion

Add a Desktop → View Server URL/Credentials debug menu item, OR fall back to no-auth if OPENCODE_SERVER_PASSWORD is empty on the serve side (matching CLI behaviour). Currently the desktop's bundled serve enables Basic Auth when the same env var that triggers it in CLI is also set during desktop startup — but the Renderer doesn't receive matching credentials.

Reported via desktop user's claude (Mautoer) session, 2026-08-27.