Introduction¶

After using the DeepSeek Harness desktop application on Windows for a while, it might suddenly fail to open on a specific startup with the error Web authentication failed. Troubleshooting often starts by suspecting an expired login state or Host port conflicts, but the actual cause is that the Cookie library is stretched too large by login Cookies: every startup adds another dsh-auth-* that is never cleaned, accumulating to about 70 when the Cookie request header exceeds Node’s default 16 KB limit, causing the local Host to directly return a 431.

The m0yun/dsh-cookie-guard introduced below is a plugin targeting this specific issue. It does not shell-wrap shortcuts or change the startup method; instead, it mounts a background cleaner during DSH startup, which deletes the previous round and older dsh-auth-* after DSH exits, ensuring the next startup is clean.

What is it¶

dsh-cookie-guard is maintained by M0Yun, categorized under admin-security, and has a star count of 1 on the directory page. Its positioning is very specific: a background cleaner for residual dsh-auth-* login Cookies on the DSH desktop, resolving the inability to open caused by Cookie accumulation (431). The license is MIT.

The root cause lies in @deepseek-ai/dsh-client-connection: Cookie names are derived from the authority hash,

const COOKIE_PREFIX = "dsh-auth-";
function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}
// authority = "127.0.0.1:<random_port>"

The Host changes to a random port every startup, so Cookie names differ every time; Max-Age is in the tens of days, Chromium does not clean it proactively, and DSH has no code to delete old Cookies. The accumulation grows linearly with the number of starts:

Core Functionality¶

The cleaner works in three steps:

1. When the plugin loads (Host starts), it detachs an independent cleaner process lib/cleaner.mjs; the parent process does not affect it even if it exits.
2. The cleaner probes every 15 seconds to see if the Cookie library can be opened exclusively. If not, it means DSH is still running (Chromium has exclusive access to the file), so it continues to wait. If it can be opened, it means DSH has exited, it immediately executes delete from cookies where name like 'dsh-auth-%' plus VACUUM, and then exits itself.
3. On the next startup, only the one entry for this round remains in the library, and the request header stabilizes at a few hundred bytes.

The cleanup uses node:sqlite (built-in in Node 22.5+), has no third-party dependencies, and does not require Python or PowerShell. The plugin directory structure is as follows:

lib/index.js      cordis plugin: registers cookie_guard tool + starts cleaner
lib/cleaner.mjs   background cleaner: waits for lock release → deletes dsh-auth-* → exits
cordis.patch.yml  bundle registration line

Installation and Usage¶

The installation commands come from the original README; install directly from the repository:

# Install directly from the repo (recommended)
dsh plugin add github:M0Yun/dsh-cookie-guard

# Or install a local directory
dsh plugin add D:\path\to\dsh-cookie-guard

One thing to note: the dsh-cookie-guard on npm is not this repository; that is someone else’s package with the same name (0.1.1). Do not use dsh plugin add dsh-cookie-guard.

After installation, restart Harness, and the plugin will start working. Subsequently, you can simply turn DSH on and off normally without changing any usage habits. Rollback command:

dsh plugin remove dsh-cookie-guard

The plugin only writes Cookies.guard.pid and Network.guard.log in %APPDATA%\@deepseek-ai\dsh-desktop\Network\, just delete them when uninstalling.

Typical Usage¶

The agent side exposes a tool cookie_guard with two actions:

Status logs are written to %APPDATA%\@deepseek-ai\dsh-desktop\Network.guard.log, one line per cleanup, like:

2026-11-04T16:17:24.467Z pruned 60 cookie(s); 62 -> 2

You can confirm if the cleanup actually happened based on this format without guessing if the plugin is effective.

Applicable Scenarios and Notes¶

Suitable for DSH users on Windows desktop with frequent starts that have encountered 431 or Web authentication failed. Pay attention to the following points before using:

• Only cleans dsh-auth-*; other Cookies (including platform login) are left untouched.
• Cleanup happens after DSH exits: during the current startup session, the library still contains the amount accumulated from the previous round; you need to exit DSH once after the initial installation to see the effect for the first time.
• If DSH is not closed for a long time, the cleaner will keep waiting. By default, it waits for a maximum of 24 hours, which can be adjusted via config.maxHours.
• Only supports Windows desktop; Web/headless are not affected.
• The plugin runs with the permissions of the current dsh process and will read/write the DSH Cookie library and log files under %APPDATA%. Before installing, check the source code and license (MIT © M0Yun) to ensure it matches your environment.

Conclusion¶

The value of dsh-cookie-guard lies in turning a difficult problem to troubleshoot manually (startup failure, abnormal login state) into a cleanup automatically completed after an exit, limiting the scope of change to dsh-auth-* without affecting other Cookies. Directory page: https://www.skillhub.cn/plugins/M0Yun/dsh-cookie-guard ; Repository: https://github.com/M0Yun/dsh-cookie-guard . This directory site is a community site and has no official affiliation with DeepSeek / Hypothesis.