DSH Desktop 431 startup recovery

DSH Desktop HTTP 431: Random-Port Cookie Accumulation

Author
DeepSeekAgent.io Editorial Team
Published
Updated

A Windows community case on DeepSeek Harness Desktop v0.2.1-rc.3 produced a repeatable startup crash: launching the application opened no window, the main-process log stopped at desktop welcome: Web authentication failed, and neither restart nor reinstall recovered it. The underlying HTTP status was 431—request headers too large.

The failure emerged from three conditions: random Desktop GUI ports, authentication cookie names derived from the authority, and a three-day lifetime. Every Host port change added another dsh-auth-* cookie to Electron's cookie jar. Older entries had different names and were not replaced. Once their combined size approached Node.js's header limit, the Desktop Welcome request carrying the jar was rejected and the main process exited.

Why Web authentication succeeds while Desktop fails

Startup uses two network clients:

  1. the browser completes Web authentication;
  2. Desktop uses Electron networking and its own cookie jar to connect to the local Host.

The browser-side step does not carry Electron's accumulated local cookies, so authentication can appear successful. The Desktop request then sends cookies matching 127.0.0.1. Although each cookie name encodes a different port, cookie scope is matched by host and path. Credentials left by old random ports therefore travel to the current port together.

The result looks contradictory: the account and Web flow succeed, yet Desktop reports a Welcome authentication failure. The visible message identifies the stage but hides the underlying 431 response.

How 71 cookies exceed 16 KiB

The reproduction reports a cookie name derived from the hash of 127.0.0.1:<port>, with each cookie consuming about 227 bytes and retaining a three-day Max-Age. Frequent Host restarts and plugin install or uninstall cycles create new random GUI ports while old cookies remain valid.

The affected jar contained 71 matching cookies, approximately 16.1 KiB before accounting for separators and other headers. That reaches Node's default 16,384-byte maximum header size, so the Host returns HTTP 431. Every later launch reuses the same jar, turning gradual accumulation into a stable crash.

Reinstalling the application often preserves Electron's Network Cookies database under user data. Restarting simply repeats the same oversized request. This explains why both common recovery attempts fail.

Confirm the same failure chain

Look for this combination:

  • Desktop rc.3 with frequent recent Host restarts or plugin operations;
  • main-process logs ending at desktop welcome: Web authentication failed;
  • successful Web authentication followed by immediate Desktop exit;
  • an HTTP 431 response or a Cookie header approaching 16 KiB;
  • many dsh-auth-* records for 127.0.0.1 in Electron cookie storage.

Without 431 or header-size evidence, investigate system time, proxy behavior, account state, and connection errors as separate causes.

Keep recovery narrowly scoped

The community case recovered after the application was fully closed and 71 records matching host_key='127.0.0.1' and dsh-auth-* were removed. That validates the diagnosis, but users should not edit a live SQLite database or delete the entire Desktop data directory.

A safer sequence is:

  1. fully quit DSH Desktop and verify its processes have ended;
  2. back up the Network/Cookies database;
  3. prefer a product-provided sign-in reset or cookie cleanup action;
  4. only after confirming 431, limit any manual repair to the matching local DSH authentication records;
  5. authenticate again and verify Sessions, Profiles, and Workspaces;
  6. retain logs and cookie counts for an upstream reproduction.

Deleting all user data can remove unrelated state and make recovery harder.

Preventing recurrence

The product can address both cookie lifecycle and authentication design:

  • delete old-port local authentication cookies after a new port connects;
  • shorten local one-time cookie lifetime and cap retained entries;
  • avoid creating a new cookie name for every port;
  • measure header size before Welcome and clean up with an explicit message;
  • map HTTP 431 to a local-cookie diagnostic instead of a generic Web authentication failure;
  • stress-test random-port restarts, repeated plugin toggles, and upgrades.

For users, the architectural boundary is useful: successful Web sign-in proves only the browser phase. Desktop still maintains a separate local connection and cookie state. Logging those phases separately makes startup failures much easier to identify.

References

FAQ

Why does reinstalling Desktop not recover the application?

The application directory and Electron user-data directory are separate. Reinstall can preserve the Network Cookies database, causing the same oversized request on the next launch.

Why can the Web page report success while Desktop reports authentication failure?

The browser and Desktop Welcome use different network clients. The latter carries Electron's accumulated cookie jar and can receive HTTP 431.

Should I delete the complete Cookies file?

Back it up and prefer a supported reset. If a manual repair is required, scope it to the confirmed local DSH authentication records.