[desktop] Intermittent "desktop welcome: Web authentication failed" on startup (0.2.2-rc.1, macOS)

[Jfreey]

[desktop] Intermittent "desktop welcome: Web authentication failed" on startup (0.2.2-rc.1, macOS)

Summary

On macOS (Apple Silicon), the DSH desktop app intermittently aborts at startup with desktop welcome: Web authentication failed. Relaunching the same build on the same machine succeeds sometimes and fails other times, with no environment difference between failing and succeeding launches.

Reproduction

1. Install the 0.2.2-rc.1 desktop build (macOS arm64).
2. Launch the app and let it boot to the welcome stage.
3. Observe the fatal dialog: desktop welcome: Web authentication failed.
4. Relaunch. The outcome is nondeterministic: some runs succeed, some fail. (Observed: three consecutive failures, then consecutive successes, then five+ consecutive successful relaunches — same build, machine, and profile throughout.)

Minimal controlled reproduction (vanilla Electron app driving the same host flow):

• Start the desktop-host flow the same way the app does (token URL on 127.0.0.1:<port>).
• From the Electron main process, issue the exact handshake the app uses: net.fetch(tokenUrl, { credentials: "include" }).
• Result: nondeterministic 401 vs 200 against the same host flow; the identical call succeeds against a fresh host.

Current behavior

Crash dialog:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (app.asar/lib/main.js:16856:31)

In the 0.2.2-rc.1 build, connectDesktopWelcome (welcome-backend) performs the host handshake through the Electron session fetch:

const authenticated = await send(authenticatedUrl, { credentials: "include" });
await authenticated.body?.cancel();
if (!authenticated.ok) throw new Error("desktop welcome: Web authentication failed");

The exchange is GET http://127.0.0.1:<port>/?token=... → 303 + Set-Cookie → redirect follow with the cookie → 200. Both ends of this handshake are app-owned and loopback-only.

External factors ruled out:

• No proxy on loopback (verified with scutil --proxy / networksetup).
• The failure happens at the welcome stage, before workspace/session boot (plugin loading is not involved).
• The launch token is not single-use — per the host code the token stays valid for the host process lifetime.
• Cross-generation cookie clash: the cookie name embeds a hash of 127.0.0.1:<port>, so different generations cannot collide by name.

Suspected causes:

1. A race between the host emitting the launch URL and the main process's fetch arriving, or
2. Cookie-jar state across rapid relaunches: Chromium's cookie store is keyed by host+path (the port is not part of the key), and welcome cookies accumulate in the jar across generations. If a port is reused, a stale entry could be presented instead of the freshly minted cookie.

Note: connectDesktopWelcome on master now takes an explicit cookie header and is documented as "uses no cookie jar" — if that refactor is intended to address this failure, please confirm; it is not present in the 0.2.2-rc.1 build.

Additional observations:

• The version field in crash logs (~/Library/Logs/DeepSeek Harness/crash-*.log) reports 0.2.1-rc.5 while the installed bundle is 0.2.2-rc.1 — the reported version metadata appears stale.
• Chromium switches on the command line (e.g. --net-log) appear to be ignored by the app, which made it hard to capture network diagnostics at the failure moment.

Expected behavior

The welcome handshake should complete on every launch: the token exchange returns 200 and the workspace becomes visible. A transient local-host failure should be retried internally or surfaced as a recoverable error, not a fatal dialog.

Environment

• macOS (Apple Silicon)
• DSH desktop 0.2.2-rc.1 (crash-log version field reports 0.2.1-rc.5 — see note above)
• No proxy on loopback; stock system configuration
• Crash logs available locally (~/Library/Logs/DeepSeek Harness/); they contain version, PID, and stack only. Happy to share a redacted copy if useful.