Introduction¶

When exposing the Connection service with dsh web, the startup logs print pairing links containing ?token=.... The official @deepseek-ai/dsh-client-connection generates a new launch token using randomBytes(32) every time the process starts. This value simultaneously validates against both /connect and GET /?token=. To save the link to bookmarks, scripts, or internal documentation, one has to copy the new token from the logs every time after a restart. Below is an introduction to the community plugin dsh-fixed-launch-token (maintainer starskyzheng, category admin-security): under the premise of explicit configuration, it changes the running browserAuth.launchToken to a fixed value specified by you, and the startup banner and access paths uniformly use this token; if not configured by default, the official random behavior is not modified.

What is it¶

dsh-fixed-launch-token is a Cordis plugin in the DeepSeek Harness (DSH) ecosystem. It injects the connection service via cordis.patch.yml and overrides service.browserAuth.launchToken with the configuration item fixedLaunchToken after the random token is generated. It does not replace the official Connection provider, nor does it skip BrowserAuth; unlike @iasiv5/dsh-skip-browser-auth, the validation logic and Host/Origin trust fence remain unchanged. Invalid tokens still return 401, and forged Hosts still return 403.

Core Features¶

1. Fixed Startup and Access Token: After the configuration takes effect, the dsh web banner, /connect?token=..., and /?token=... all use the same fixed value.
2. Default Lazy: When fixedLaunchToken is not set, the plugin does not modify behavior, and the official random token per process remains the same; the logs will indicate the plugin is loaded but not enabled.
3. Configuration Validation: Token length is 16–256; whitespace characters and ?, # are prohibited. Too short or invalid values will throw errors, avoiding the misconception that it is fixed when it is still random.
4. Compatibility Gate: The top-level engines.dsh in package.json is declared as 0.2.1-rc.2 || 0.2.2-rc.1. Unverified DSH versions will skip this bundle and provide a clear reason.

Installation¶

Local directory installation (original README command):

dsh plugin --profile <your profile> add /path/to/dsh-fixed-launch-token

You can also install this directory in the GUI plugin management. If no configuration is written after installation, the behavior is the same as without the plugin.

Uninstallation:

dsh plugin --profile <your profile> remove dsh-fixed-launch-token

Configuration and Enabling¶

Override config in your own profile by plugin id (user patch has the highest priority), path example:

~/.dsh/profiles/<your profile>/cordis.patch.yml

- id: fixed-launch-token
  config:
    fixedLaunchToken: "在此处填写你的固定值"

You can use the following command to generate a ~43-character base64url strong random value (32 bytes of entropy):

head -c 32 /dev/urandom | base64 | tr '+/' '-_' | tr -d '=\n'

Restart dsh web after modification to take effect; this value is read once when the plugin applies. Empty strings, omitting config, pure whitespace, null, or non-string types are all considered not enabled; only non-empty and valid strings will fix the token.

Typical Usage and Scenarios¶

Applicable scenarios: GUI pairing links need to remain constant for a long time—saving to bookmarks, embedding in automation scripts, writing to team documentation, without needing to check logs every restart.

The access method remains the official semantics, for example in the logs:

dsh web: https://<public-url>/?token=<your fixed value>

Note: The fixed token becomes a long-term credential. Its validity lasts until you change the configuration; unlike random tokens, it does not expire on restart. The plugin runs with the permissions of the current dsh process. Before installing and enabling, you should review the source code and MIT license in the GitHub repository.

How It Works (Brief Overview)¶

The official processLaunchToken stores the token in a non-exported module private structure; this plugin rewrites browserAuth.launchToken in the ctx.inject(['connection'], ...) callback, making authorizeConnect, authorizeIndex, and authenticatedUrl read the same field. If the official implementation changes the shape of this field in the future, the plugin is designed to throw an error rather than silently falling back. It only makes sense in the dsh web scenario where the connection service exists; in profiles without a webServer, this line remains dormant.

Testing and Versioning¶

Testing in repository:

node --test tests/plugin.test.mjs

Please pass the test file directly; passing a directory with node --test tests/ may fail due to MODULE_NOT_FOUND.

Current package version is 1.0.0, tested compatible with DSH 0.2.1-rc.2 and 0.2.2-rc.1; other versions may be skipped by the compatibility gate rather than silently downgrading.

Conclusion¶

dsh-fixed-launch-token changes the launch token from “random on each start” to “configurable fixed” while preserving the official BrowserAuth, and has zero impact if not configured by default.

Directory and source code:

• Community Directory: https://www.skillhub.cn/plugins/starskyzheng/dsh-fixed-launch-token
• GitHub: https://github.com/starskyzheng/dsh-fixed-launch-token

The DSH community plugin directory is an independent site with no official affiliation with DeepSeek / Fenxiang. When choosing a plugin, please evaluate the risk of fixed credentials based on your own security requirements.