Fix DeepSeek Harness sessions not opening after plugin add

Sessions stopping to open after dsh plugin add, reporting preset standard failed to mount — usually the preset is fine; the on-disk session.jsonl.zstd was dirtied by some write (seq gap, unknown event type, or a user/message missing id), and the official recovery path refuses the whole file after restart. Inspect the file health with dsh-session-surgeon, handle it by health category (dry-run then apply, always backing up first); for unknown-type, uninstall the plugin that wrote the events. A preset mount failure is a config/plugin issue — fixing the file will not restore the preset, but Web usually starts again once the bad log is moved away or repaired.

What sessions-not-opening after dsh plugin add looks like

The symptom is "Resumed Failed For Session" plus preset standard failed to mount, appearing after a plugin install and restart. A reporter hit it in practice (discussion thread):

1. The reporter ran dsh plugin add to install the dsh-web-search-exa plugin;
2. After restarting, sessions would not open — "preset standard failed to mount" plus Stopped Working;
3. The key insight: the error points at preset/plugin mounting, but what really breaks the session is usually the session file itself being dirtied — a write triggered by the plugin install (or concurrent writes) pollutes the on-disk session log.

Common root cause: session.jsonl.zstd dirtied by a write

Sessions failing to open after dsh plugin add usually means the on-disk session.jsonl.zstd was dirtied by some write, and after restart the official recovery path refuses the whole file. The community distilled three pollution shapes (source):

1. seq gap: event sequence numbers with gaps (often from concurrent writers — see Fix "corrupt session log: seq gap" in DeepSeek Harness);
2. Unknown event type: a plugin wrote unknown-type events the official does not recognize;
3. Missing id: user/message events lack an id and fail during materialization.

Whichever it is, the official recovery strategy is "refuse the whole file" — better not to open it than to risk recovering dirty data.

Troubleshooting: inspect the file health with Session Surgeon

The inspection tool is dsh-session-surgeon, which bypasses official history materialization and looks at file health before deciding whether to repair. Step by step:

1. Install the tool: run:

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

2. Locate the session file: confirm where the problematic session lives on disk (session.jsonl.zstd):

ls -lh ~/.dsh/profiles/<name>/sessions/

3. Restart: restart dsh web (Ctrl+C, then start it again) and pick the problematic session in the left Session Surgeon panel;
4. Read the inspect output: paste the health / issues summary (do not upload the whole session file, only the health digest);
5. Handle it by health category, as in the next section.

Handling by health category

Two repair paths — assess first, act second, and always back up first. Concretely:

1. seq-gap-* / torn / message-missing-id: dry-run preview by default, then apply after confirming (the tool drops a .bak.<utc> backup first); missing ids are only filled in, no content is lost;
2. unknown-type: a plugin wrote events the official does not recognize. Do not patch ignorable onto other people's custom events, and do not delete lines — uninstall that plugin first, or move the session dir out of ~/.dsh/sessions and start a new session;
3. Handle preset standard failed to mount separately: this is a config/plugin mounting problem; fixing the file will not restore the preset — but after moving away or repairing the bad log, Web usually starts again. Keep the two tracks separate.

Community note: the reporter later tried rm -rf on the submodules in the npx cache (node_modules/@deepseek-ai/*) — that is a cache cleanup action, unrelated to session repair. Inspect the session file health first; do not chase the wrong direction.

Fix and prevention: trustworthy sources and centralized management

The repair order is "back up → inspect health → repair by category → move away/uninstall the abnormal source → restart"; the prevention essentials are installing from trustworthy sources and avoiding plugins that write unrecognized events into sessions. Installing a plugin is not dangerous per se; what is dangerous is a plugin dirtying the session/config environment invisibly. If you want the install process more controllable and everything you installed visible at a glance, the desktop app's built-in DSH Plugin Hub (dsh-plugin.org) centralizes plugin installation and uninstall — each plugin's source, status, and session impact is viewable, so problems surface early and cleanup is quick.

Notes

1. Move away or repair the bad session log before restarting Web — otherwise every restart stalls on recovering the dirty session.
2. Do not upload the whole session file when asking for help; paste only the inspect health/issues digest.
3. For the seq-gap class root cause and its fix, see Fix "corrupt session log: seq gap" in DeepSeek Harness.
4. Similar plugin errors are collected in the DeepSeek Harness plugin error collection: DSH plugin not loading, Web UI issues, and session cache repair.

Sources: Discussion #4263, dsh-session-surgeon, #4598 (seq gap root cause)