DSH Desktop won't start: desktop welcome: Web authentication failed — fix by clearing Network/Cookies

[wang-b]

DSH Desktop won't start: desktop welcome: Web authentication failed — fix by clearing the Electron Network/Cookies store

Symptoms

On Windows, DSH Desktop (DeepSeek Harness desktop app) starts, then exits before the window appears. Every launch leaves a crash log, and reinstalling the app does not help.

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///D:/deepseek/dsh/resources/app.asar/lib/main.js:8886:31)
    at async Object.start (.../lib/main.js:12195:22)

Environment where this happened: Windows, app @deepseek-ai/dsh-desktop 0.2.1-rc.3, Electron 44.7.0, Node 24.21.0.

Root cause

The desktop app boots a local web host and authenticates itself against it. The flow has three steps:

1. authenticateWebHost(url) — Node.js fetch on the launch URL, expects 303 + Set-Cookie.
2. The same URL is passed to connectDesktopWelcome(), which requests it again through Electron's net.fetch with credentials: 'include' and expects a 2xx response.
3. The host's BrowserAuth sets a SameSite=Strict cookie and, on subsequent requests, redirects (303) instead of returning the page.

The bootstrap expects that second request to return the welcome page. When the Chromium cookie store is in a bad state (an interrupted write or a corrupted SQLite Cookies file), the cookie set by step 1 is not applied for step 2, the request gets 401, and the whole startup aborts with the error above. The crash is deterministic, so every retry and every reinstall produces the same failure.

This is not a plugin, profile, or API-key problem: the crash happens during host authentication, before any profile or plugin loads. The app's own profile directory (.dsh) and the app install are untouched, so nothing needs to be reinstalled.

Fix

Fully quit DSH Desktop, then delete (or rename) the Electron cookie store and start the app again. The app recreates it on the next launch.

Windows

# 1. Quit DSH Desktop completely (also from the tray).
Stop-Process -Name "DeepSeek Harness" -Force -ErrorAction SilentlyContinue

# 2. Remove the corrupted cookie store (rename instead of delete if you want a backup).
$dir = Join-Path $env:APPDATA "@deepseek-ai\dsh-desktop\Network"
Rename-Item "$dir\Cookies" "Cookies.bak" -ErrorAction SilentlyContinue
Remove-Item "$dir\Cookies-journal" -Force -ErrorAction SilentlyContinue

# 3. Start DSH Desktop again.

macOS

# 1. Quit DSH Desktop completely.
# 2. Move the cookie store aside.
DIR="$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Network"
mv "$DIR/Cookies" "$DIR/Cookies.bak" 2>/dev/null
rm -f "$DIR/Cookies-journal"
# 3. Start DSH Desktop again.

Linux

# 1. Quit DSH Desktop completely.
# 2. Move the cookie store aside.
DIR="$HOME/.config/@deepseek-ai/dsh-desktop/Network"
mv "$DIR/Cookies" "$DIR/Cookies.bak" 2>/dev/null
rm -f "$DIR/Cookies-journal"
# 3. Start DSH Desktop again.

After the restart the Network/Cookies file is recreated (in our case it went from ~52 KB with stale dsh-auth-* cookies to ~20 KB), and the window opens normally.

Verification

• A new Network/Cookies file exists after launch.
• No new crash-*-host.log appears under %APPDATA%\@deepseek-ai\dsh-desktop\logs.
• The app window appears and the session list loads.

Why reinstalling doesn't help

A reinstall replaces the application files under the install directory but keeps the user data directory (%APPDATA%\@deepseek-ai\dsh-desktop). The corrupted Network/Cookies file lives in that user data directory, so the failure survives reinstalls. Only clearing that store fixes it.

Notes

• If you keep other apps' sessions in the same Electron store, deleting it only signs you out of the desktop app; local sessions, profiles, and plugin data live elsewhere (.dsh).
• If the problem persists with a freshly recreated cookie store, please attach the newest crash-*.log here.

---

中文摘要：DSH Desktop 在 Windows 上启动后闪退、日志报 desktop welcome: Web authentication failed 时，通常是 Electron 的 Cookie 存储损坏导致认证凭据无法传递。彻底退出桌面端后删除 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（以及 Cookies-journal），再启动即可；重装无效是因为用户数据目录不会被清除。macOS/Linux 的对应路径见上文。

[PerryLink]

Your recovery is right. The reason it comes back is one line in the cookie name.

packages/client/connection/src/browser-auth.ts:116-118 derives the name from a hash of the authority:

function cookieName(authority: string): string {
  return COOKIE_PREFIX + encodeBase64Url(createHash('sha256').update(authority).digest())
}

requestAudience (:78-88) returns url.host for http and url.origin for https (:84) — both keep a non-default port. The desktop launches the host without a port argument (apps/desktop/src/host-process.ts:201-208) and learns the URL back from the child, so the port is chosen at runtime — and your 71 distinct names over 71 launches are the evidence that it changed each time. A changed authority mints a new dsh-auth-<43 chars> name; sessionCookie (:131-140) sets Max-Age and nothing ever deletes the older ones. A cookie for 127.0.0.1 is sent to every port on that host, so the jar gains one entry per launch until the request header crosses maxHeaderSize and the Host answers 431 — which the welcome flow surfaces as Web authentication failed.

That is also why reinstalling does not help and clearing the cookie store does: the jar lives under Electron's userData, not under the install. apps/desktop/README.md:264 describes the contract — a plain uninstall removes that directory, while an in-place update runs the uninstaller with --updated and retains it; the harness home is separate either way.

The durable fix has two halves: stop hashing the port into the name, and delete sibling dsh-auth-* cookies on startup so an already-poisoned jar recovers without the user knowing to clear anything.