[0.2.2-rc.1][Windows] First launch after update re-initialized $DSH_HOME — all workspaces, sessions and plugins gone

[naturalth2012]

[0.2.2-rc.1][Windows] First launch after update re-initialized $DSH_HOME — all workspaces, sessions and plugins gone

TL;DR (中文)

2026-11-05 18:19:55（UTC+8），Windows 桌面端 0.2.2-rc.1 在一次启动中把 %USERPROFILE%\.dsh 按“全新安装”重建：

• storages\workspace.json 只剩一个当天新建的 default-workspace；
• profiles\desktop\package.json 变成 211 B、dependencies: {} 的默认模板；
• .anonymous-user-id / .credentials.yaml 重新生成，被迫重新登录；
• 更新前存在 6 个工作区、多个本地插件和 12 个旧会话，现在 UI 里全部消失。
• 项目目录没有丢；旧会话正文只剩 storages\session_projcache\sessions\*.json。

这与 #9940（0.2.1-rc.1）、#7921（0.1.7-rc.1 → rc.2）、#9309（静默以空 profile 重建）属于同一类故障，这次发生在 0.2.2-rc.1。

Environment

• Windows 11 22H2, build 22621.4317 x64 (ProductName reports Windows 10 Pro)
• DeepSeek Harness Desktop 0.2.2-rc.1, update channel nightly (install dir created 2026-11-04 22:22:30 local)
• Previous version: 0.2.1-rc.5 (from %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-11-04T*.log)
• DSH_HOME=%USERPROFILE%\.dsh, DSH_PROFILE=desktop
• Update was on disk at 11/04 22:22; the old process continued to be used until 11/05 08:54 (see plugin operation log). The new storages/ layout first appears at 11/05 18:19:55, i.e. the first effective launch of the new build happened then.

Timeline (local UTC+8, filesystem timestamps)

Time	Observation
11-04 22:22:30	install dir ...\Programs\DeepSeek Harness created; app version 0.2.2-rc.1
11-05 08:34	last old session created (project root on D:)
11-05 08:54:17	last plugin-operations entry (quant-lab enable)
11-05 08:59:20	%USERPROFILE%\.dsh\profiles LastWriteTime; no further writes until evening
11-05 18:19:55	storages\ and lantern\ created; 12 session_projcache\sessions\*.json files created in the same second
18:20:16	profiles\desktop\{package.json, cordis.yml, pnpm-workspace.yaml} created; package.json is 211 B with dependencies: {}
18:20:18	.anonymous-user-id created
18:20:21	sessions\ created; storages\workspace.json contains exactly one default-workspace (created 18:20:21)
18:21:01	desktop processes (re)started
18:22:28	.credentials.yaml and cordis.patch.yml created — sign-in required again

Evidence

E1. Host data directories were created anew

Get-Item "$env:USERPROFILE\.dsh",
         "$env:USERPROFILE\.dsh\storages",
         "$env:USERPROFILE\.dsh\sessions",
         "$env:USERPROFILE\.dsh\profiles\desktop",
         "$env:USERPROFILE\.dsh\profiles\desktop\package.json",
         "$env:USERPROFILE\.dsh\.credentials.yaml" |
  Select-Object FullName, CreationTime, LastWriteTime

C:\Users\<user>\.dsh                              C=2026-08-14 14:09:58  W=2026-11-05 18:22:28
C:\Users\<user>\.dsh\storages                    C=2026-11-05 18:19:55  W=2026-11-05 18:20:21
C:\Users\<user>\.dsh\sessions                    C=2026-11-05 18:20:21  W=2026-11-05 18:20:21
C:\Users\<user>\.dsh\profiles\desktop            C=2026-09-30 10:16:55  W=2026-11-05 18:22:28
C:\Users\<user>\.dsh\profiles\desktop\package.json C=2026-11-05 18:20:16 W=2026-11-05 18:20:16
C:\Users\<user>\.dsh\.credentials.yaml           C=2026-11-05 18:22:28  W=2026-11-05 18:22:28

The profile directory is old (2026-09-30) but its files are new (18:20:16). This is not a whole-home copy; the data units were re-created inside a surviving directory.

E2. package.json was regenerated as the 211-byte default

{
  "name": "dsh-profile-desktop",
  "private": true,
  "dependencies": {},
  "dsh": {
    "profile": {
      "bundles": [
        "@deepseek-ai/dsh-base",
        "@deepseek-ai/dsh-web-app"
      ]
    }
  }
}

The installed 0.2.2-rc.1 bundle's initProfile() only writes this manifest when package.json does not exist. So the old manifest (with plugin dependencies) was absent before 18:20:16.

E3. Only the default workspace was written

storages\workspace.json has one entry created at 2026-11-05T10:20:21Z, path ...\Documents\deepseek-harness\default-workspace. No old workspace paths.

E4. Sign-in state was re-created

.anonymous-user-id (18:20:18) and .credentials.yaml (18:22:28) are new files, and the UI asked for sign-in again at 18:22. An upgrade should not remove credentials.

E5. The old renderer state still proves six workspaces existed

In %APPDATA%\@deepseek-ai\dsh-desktop\Local Storage\leveldb\000014.ldb (last write 08:33), the persisted dsh.workspace.view.v5 value contains 6 distinct workspace IDs in groupExpansion, and the plugin-manager.install-registry key is present. The host-side store was reset while renderer state remained.

E6. Old sessions survive only in the projection cache

storages\session_projcache\sessions\ holds 12 session files (all created 18:19:55) whose identity.cwd values cover four old project roots on D:. Their record.rows contain titles and full event rows (one file has 4,471 events), so they are still readable. They are the only surviving conversation data.

E7. Project files are intact

The project directories on D: are untouched; only DSH's workspace registry, profile dependencies, and session index were lost.

Expected vs actual

• Expected: on first launch after an update, migrate workspace.json and the profile dependency list (or at least keep them), or abort the upgrade with a visible error and a backup.
• Actual: silent fresh initialization — one default workspace, empty profile dependency list, new anonymous ID, new credentials; no warning and no backup directory (dsh-backup-* / upgrade logs do not exist).

Why this looks like the same class as #9940 / #7921 / #9309

All three reports describe the same shape: $DSH_HOME root survives, but storages, sessions, workspace.json, .credentials.yaml, .anonymous-user-id and the profile manifest are re-created within seconds; the UI then shows an empty profile and the plugin list disappears. In this case it happened on 0.2.2-rc.1, after the 0.2.1-rc.5 → 0.2.2-rc.1 nightly update, without any crash report in %APPDATA%\@deepseek-ai\dsh-desktop\logs.

The trigger may be the new storages/ root and workspace schema v2: the old workspace.json is not migrated, the new bootstrap cannot find the old profile manifest, and it falls back to the first-run seed. I cannot prove which process removed the files because the desktop app writes no boot log.

Ask

1. Please confirm whether 0.2.2-rc.1 changed the storage root / workspace schema and whether upgrade migration is expected to preserve old workspaces and profile dependencies.
2. Add a boot log: resolved DSH_HOME, profile path, bundle/dependency count, storage root, and whether the run is a fresh initialization. Today logs/ contains only crash reports.
3. Refuse to silently initialize an empty profile when a non-empty $DSH_HOME exists (storages, sessions, or a profile with dependencies). Require an explicit reset, or restore from the last backup.
4. Take a $DSH_HOME backup before applying an update and keep the last N snapshots.
5. If possible, tell us how to re-attach the 12 cached sessions to their workspaces from session_projcache; the data is still there.

Notes

• Paths and user name are redacted (<user>, project roots on D:); no credentials or session content are included.
• Related: 【Bug】0.2.1-rc.1 桌面端：崩溃后重启把 ~/.dsh 重新初始化，全部插件/工作区/会话丢失（无 boot log） #9940, [Bug] Data dir re-initialized during 0.1.7-rc.1 → rc.2 upgrade (Windows): all sessions / history / plugin state lost — forensics + reproduce commands attached #7921, [事故取证] 外部批量删除清掉 ~/.dsh 运行时目录与 profile：桌面端应用日志为空、会话正文丢失，重启后静默以“空 profile”重建（插件市场空白） #9309, # [Bug] Sidebar history sessions and workspaces completely lost, and current session has no corresponding entry (Data loss risk) #7637, [0.2.2-rc.1] Opening a cold session removes it from the sidebar and disables the composer #12277.

[aturzone]

Confirming one deterministic amplifier of the reported symptom on current master fcc0ad4621 — and a safety patch, while being explicit that it does not explain why the data units disappeared.

What is reproducible (no model, no Desktop needed). Take a shipped profile directory that still has state but lost package.json:

DSH_HOME=/tmp/dsh-incident
mkdir -p $DSH_HOME/profiles/web/node_modules/some-plugin
printf -- '- id: custom\n  config: {}\n' > $DSH_HOME/profiles/web/cordis.patch.yml
# no $DSH_HOME/profiles/web/package.json
pnpm dsh --profile web --dump-config

On unmodified master this exits 0 and silently writes the 211-byte default manifest — exactly the artifact in your E2 — replacing the installed bundle list with the shipped template. With the patch below it fails with:

Error: profile …/profiles/web has existing state (node_modules) but no package.json;
refusing to initialize a fresh profile over it. Restore the profile manifest from a backup,
or remove the profile directory to reset it.

and leaves the directory untouched (package.json still absent).

Why this matters for this failure family. Whatever removed the files (#9940, #9753, #9309), a missing manifest alone must not silently erase the rest of the profile's visible state: the current initializer rewrites the manifest, then the desktop path reconciles bundles from the default list, so a recoverable directory becomes a "first run" with no diagnostic. The guard only protects the profile directory; it does not touch sessions/, storages/, or credentials, and it does not claim to explain their loss.

Patch — branch: https://github.com/aturzone/deepseek-harness/tree/fix/profile-silent-reset-guard, commit 8e14c8dfb0:

• initProfile() writes the manifest only into a directory that holds nothing beyond the initializer-owned files (cordis.patch.yml, pnpm-workspace.yaml, and Desktop's lock); any other surviving entry (for example node_modules) turns the missing manifest into a diagnostic naming that state;
• the diagnostic tells the user to restore the manifest from backup or remove the directory to reset deliberately;
• package README (EN + ZH, pairing re-recorded) states the contract.

Checks: packages/boot/app-boot/tests 5,668 tests pass (new: refusal + preserved directory + lock-only directory still initializes); pnpm run typecheck 5/5 gates; Oxlint 0 errors.

Open question for maintainers: would you prefer this fail-loud behavior, or a backup-then-reset (package.json.bak-<timestamp> + generated default) so the profile still starts? I can switch the patch to either shape. A home-level integrity diagnostic (listing which expected data units vanished before writing anything) would be a sensible next step, but it needs the team's knowledge of which absences are expected.

[naturalth2012]

Thanks — the 211-byte artifact is exactly what we saw, and the guard is a real improvement. Answering the open question:

Preference: fail-loud by default, with an explicit recovery path. Do not write the default manifest when the profile directory still contains state. The error should name the surviving state and offer three actions: restore the manifest from a backup, open the backup folder, or reset deliberately (which then takes a backup first). If the product must remain startable, my second choice is backup-then-reset with a persistent, visible banner (profiles/<name>.bak-<timestamp> plus the same for storages/sessions), not a silent reset. Silent default-write is the worst option because it converts a recoverable directory into “first run” with no diagnostic.

On this machine the guard would have caught the profile half of the incident (the 211 B manifest), although not the storages / sessions / .credentials.yaml recreation. It is still worth landing.

Recovery status here, for the record:

• 6 old workspaces re-created through the local workspace/create RPC (the old registry was gone, so new IDs; paths/titles verified from old cwds and renderer state).
• 12 local plugins reinstalled through pluginManager/installBundle; they hot-loaded, and their tools are visible in the running session again.
• 11 old sessions survive only as storages/session_projcache projections; the original session.v4.jsonl.zstd files are gone, so I exported the cached turn outlines. No backup existed.

A second guard worth adding: at boot, log DSH_HOME, resolved profile path, dependency/bundle count, storage root, and whether the run is a fresh initialization; and refuse to seed a default workspace when storages or sessions already contain data.

[aturzone]

Thanks — that is exactly the artifact reproduction I hoped would settle the mechanism, and your preference resolves the open question: fail-loud by default, no silent default-write.

What the patch already gives you:

• no default manifest when surviving state exists;
• the error names the surviving entries (node_modules, …) so the profile is identifiable;
• the directory is left byte-identical, so a manual restore is possible.

What it does not give you yet is the explicit recovery action to pair with the diagnostic. Today a deliberate reset is "remove the profile directory", and --from-default-profile replaces by deletion without a backup, so neither path takes the backup you asked for as the second choice. Two follow-up shapes I can prepare, tell me which you (and the maintainers) want:

1. fail-loud + documented reset: keep the guard, and specify in the diagnostic the exact reset command/sequence (including profiles/<name> backup instructions); no new CLI surface.
2. backup-then-reset: an explicit reset action renames the existing profile directory to profiles/<name>.bak-<timestamp> (and reports the path) before writing the template, with the same growth/retention trade-off as other .bak siblings.

I would not make backup-then-reset the default for a missing manifest, because the missing file is itself the evidence that something else went wrong — but it is the right shape for a deliberate reset, which currently has no backup at all.

On the wider incident: the guard only covers the profile half. The storages/sessions regeneration is a separate path I could not reproduce from a checkout, and your forensics (CreationTime of the data units inside a surviving home/profile directory) are the best evidence we have; a read-only startup diagnostic that reports which expected data units are missing before any initialization would be the other half, if the team wants it.