DeepSeek Harness slow startup: causes and fixes for dsh

Slow dsh startup falls into three distinct cases: the first start is initializing a profile, every later cold start is composing plugin layers, and an apparent hang is usually a wait on a network timeout. Every DeepSeek Harness plugin is composed inside the dsh process, so the same three cases apply to all DSH plugins, yet the remedies differ completely. This article gives a measurable sequence: time it, count the layers, then bisect.

DeepSeek Harness slow startup, case one: first-run init, per-start composition, or a hang

The three causes leave completely different evidence: a slow first start comes with a profile directory being built from scratch; a slow start every time means the fixed composition workload is large; and a process sitting at idle CPU without ever opening a port is usually waiting on a timeout rather than computing (source). Four steps settle which one it is:

1. Check whether this is the first run — run ls "$DSH_HOME/profiles/web" before startup, then again while it starts. Expect: on first use the directory is filled in during startup (package.json and node_modules appear progressively); after several runs it is complete from the outset.
2. Check whether every start is slow — start three times and record the time from issuing the command to the browser opening http://127.0.0.1:3080. Expect: only the first being slow means initialization cost; all three being slow means workload or disk.
3. Check whether the process is working — in another terminal run top -pid <PID> (on Windows, watch the process CPU in Task Manager). Expect: CPU near zero with no new log lines means it is waiting, not being slow.
4. Check whether the port is listening — run lsof -i :3080 (Windows: netstat -ano | findstr 3080). Expect: no listener while the process still exists means it has not reached the listening stage yet.

If it turns out the process never starts rather than starts slowly, take the other path: DeepSeek Harness won't start: layered diagnosis for dsh startup errors.

DeepSeek Harness slow on every start: time config composition, then count the layers

The most controllable part of startup is config composition, which stacks each bundle's patch into the final config tree; it can be timed without starting the server, so it makes the best baseline (source). Four steps narrow the slowness down to specific plugins:

1. Time composition — run time dsh --profile web --dump-config > /dev/null. Expect: a baseline in seconds; run it three times and keep the stable value rather than a lucky fast one.
2. Count the loaded layers — run dsh --profile web --dump-config | grep -c "^# ==". Expect: the number printed is the active bundle layer count, and it grows with what you installed.
3. Compare against a minimal profile — run time dsh --profile headless --dump-config > /dev/null. Expect: a clear gap between the two baselines means the slowness sits in what the web profile has installed rather than in dsh itself; both being slow points at the environment.
4. Bisect — first run pnpm list --depth 0 in the profile directory to note the list, then remove only the few most recently installed plugins and time again. Expect: if the time drops, the culprit is among those packages; change one plugin at a time and converge.

Why the layer count equals the workload: in --dump-config output every active bundle appears as a line # == <name>, so the layer count equals the number of packages composed and resolved at startup. That is a number you can count, not a vague sense that a lot got installed.

DeepSeek Harness slow only the first time: profile initialization and dependency install

When a built-in profile such as web or headless is used for the first time, it initializes its directory layout from the shipped template and installs dependencies; that step is the slowest one in the whole lifecycle and never repeats (source). Three things to keep straight:

• What initialization covers: generating the profile directory and package.json, writing cordis.patch.yml, and installing dependencies into that profile's node_modules. For where those files land, see Where DSH plugins are installed in DeepSeek Harness.
• What normal looks like: if the terminal or log keeps producing output during the wait, it is making progress; only silence combined with an idle CPU warrants a hang investigation.
• How to confirm this is the cause: start the same profile once more after initialization completes. Expect: noticeably faster, which proves the earlier run was a one-time initialization rather than an anomaly.

Slow first downloads and first installs are a separate topic; see Installing DeepSeek Harness for the first time.

DeepSeek Harness environment-level slowness: proxy waits and disk I/O

Once workload is ruled out, the remaining slowness comes from external waits: plugins that talk to the network during startup (update checks, fetching the available model list) each wait until timeout when the proxy is unreachable, and putting $DSH_HOME on a network or external drive slows down resolving a large number of link paths. Four steps to verify:

1. Retry with a proxy — start once more using the same proxy configuration as your install channel. Expect: a clear speedup means the delay is network waiting, so fix the proxy instead of removing plugins.
2. Move to a local disk and compare — back up $DSH_HOME, then point it at a directory on a local SSD and start once. Expect: a clear speedup means I/O is the bottleneck, and keeping the data directory local is the fix.
3. Read the startup log timestamps — find the pair with the largest gap. Expect: that gap is the real waiting point, which is far more effective than reading the whole log.
4. Do not confuse many plugins with a slow environment — keep using the headless baseline to separate them. Expect: headless also slow means environment; only web slow means plugins.

DSH plugin slow startup: things to watch out for

1. Do not delete node_modules to speed things up: the dependency manifest is still there, so startup resolves a package that no longer exists and gets slower or errors out. Use the uninstall channel instead: dsh plugin remove: uninstall a DSH plugin cleanly.
2. Change one variable at a time: bisect by removing a single plugin per round. Touching several at once makes attribution impossible and forces you to start over.
3. --dump-config does not start the server: it measures the composition stage, which is not the same as server startup time. Treat the two stages separately.
4. Compare timings under the same cold or warm conditions: the second start hits the system file cache, so comparing a warm run against a cold one produces a wrong conclusion.
5. Restarting repeatedly will not make it faster: if the time is stable and large, it is a fixed workload or a fixed wait, and only locating that stage will help.

Use DSH Plugin Hub to keep the plugin count in check

The most controllable cause of slow startup is having too many plugins, and DSH Plugin Hub is the official plugin market built into DeepSeek Harness: its installed list shows at a glance what is installed and whether each plugin came from the catalog or a manual install, making it easy to remove what you no longer use. Open the Installed page, use search and sorting to find unused plugins, and click Uninstall at the end of a row. Fewer layers means less composition work; when you suspect a newly installed plugin of slowing startup, remove it here first to verify.

Sources: dsh CLI README, DeepSeek Harness Docs - Packaging and installing plugins, deepseek-ai/deepseek-harness GitHub repository