[Desktop] 0.2.1-rc.5 startup fails with "desktop welcome: Web authentication failed" after restart

[Flamencoff]

Disclosure: This report was prepared and submitted by the user's DSH assistant on the user's behalf. The user does not write code; the assistant helped summarize the issue and run the checks below.

Environment

• Windows x64
• DSH Desktop 0.2.1-rc.5
• Electron 44.7.0
• Node 24.21.0
• locale: en

Symptom

After closing and reopening DSH Desktop, startup fails with:

DeepSeek Harness is unavailable
The application could not start or stopped unexpectedly.
desktop welcome: Web authentication failed

Clicking Restart repeats the same dialog; the desktop UI cannot be reached.

Diagnostic report

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (file:///<DSH install>/resources/app.asar/lib/main.js:8886:31)
    at async Object.start (file:///<DSH install>/resources/app.asar/lib/main.js:12195:22)
    at async file:///<DSH install>/resources/app.asar/lib/main.js:7162:5
    at async file:///<DSH install>/resources/app.asar/lib/main.js:12313:4

Background

While doing some unrelated local plugin UI work, I had temporarily changed some global UI CSS, then rolled it back. One previous restart showed a similar popup once, and clicking Restart brought DSH up. The current failure happened later, after closing and reopening, and persists across Restart.

What was checked

1. Restarted the desktop app: same Web authentication failed.
2. Temporarily reduced the desktop profile to only @deepseek-ai/dsh-base and @deepseek-ai/dsh-web-app, with no third-party dependencies, to rule out plugins. It still failed.
3. Checked the desktop host port behavior: it starts the host with --port 0 (random port), so the local web fallback on port 3080 is not a port conflict.
4. Backed up and cleared the desktop Electron auth cookies at %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies; after that, desktop started normally.
5. Restored the normal profile and it still started.

Suspected cause

A stale/invalid desktop authentication cookie or login state, after which connectDesktopWelcome treats the first non-2xx response as fatal. The crash log does not include the request URL or HTTP status, so the exact response cannot be confirmed from the report.

Workaround that worked

Close DSH Desktop, back up and remove %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies, then start again.

Expected

• Detect stale auth state and clear/refresh it automatically;
• Or open a re-login screen instead of a fatal "unavailable" dialog;
• Include the request URL (redacted) and HTTP status in the crash diagnostic.

Request

Please check whether stale desktop auth cookies can be recovered automatically. The redacted screenshot and the diagnostic steps above are included.

[PerryLink]

Two things first. The CSS you changed is not in this path, and the dialog's wording is misleading.

That message means the welcome request failed before the app rendered anything. On this build the common cause is the accumulated dsh-auth-* cookies crossing Node's 16 KiB header limit. One query settles it:

-- %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies
SELECT COUNT(*), SUM(LENGTH(name) + LENGTH(value) + 2) FROM cookies WHERE name LIKE 'dsh-auth-%';

If that returns around 70 rows / ~16 KB, you have the same failure as #11408 and #11555: back up the file, delete those rows, VACUUM, relaunch.

Why it accumulates: packages/client/connection/src/browser-auth.ts:79-84 takes the cookie authority from url.host (or url.origin), both of which keep the port; :116-118 hashes that into the cookie name; :138 gives it a 30-day life. The desktop launches the host with --port 0 (apps/desktop-host/src/index.ts:36), so each launch mints a new name and nothing removes the old ones.

Two corrections to the usual advice:

• "Restart" cannot help — the next launch mints one more cookie and pushes the header further over the limit.
• Dropping the port from the name is not free: the port is in the name on purpose (packages/client/connection/README.md:43), so one home can serve several Web ports. The minimal fix is purging sibling names when a cookie is written.

The code is unchanged between rc.5 and master ce7073d5 (same blob 5c8594df), so there is no newer build that fixes this yet.

[drscrewdriver]

pnpm install dsh-cookie-cleaner

① 先看现状（客户端开着也能跑，只会告诉你读不到）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd"

② 完全退出客户端：托盘图标 → 退出，并确认进程列表已无 DeepSeek Harness

Get-Process | Where-Object { $_.ProcessName -match 'DeepSeek|dsh' } # 应当没有输出

③ 清理（先看会删几条，再真删）

& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean --dry-run
& "$env:USERPROFILE.dsh\profiles\desktop\node_modules.bin\dsh-cookie-cleaner.cmd" --clean

[kaokxoas]

If dsh-cookie-cleaner (the fix posted above) does not restore startup, check the crash log for a second, unrelated failure mode before assuming the cookie family again:

%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*.log, phase: startup entry. If [cause] says Error: bad port, the app died before the handshake: the host is started with --port 0, the OS assigned a port that sits on the WHATWG Fetch forbidden-port list (undici badPorts), and the shell's fetch() refuses locally — no request, no 431, nothing in the host log. A plain restart draws a new port and works, which is why it looks like a one-off.

Code paths, repro and three candidate fixes: #12098.