[0.2.2-rc.1] Opening a cold session removes it from the sidebar and disables the composer

[N1ne-Nana]

Environment

• DSH Desktop 0.2.2-rc.1, upgraded from 0.2.1-rc.5
• Windows 11, version 10.0.26300
• No new crash log after the upgrade; the host process stayed responsive
• The issue also reproduces after a clean app restart

Summary

After upgrading from 0.2.1-rc.5 to 0.2.2-rc.1, three pre-existing sessions disappeared from the sidebar. Their event logs are still on disk and their IDs are still present in workspace.json (they are not archived).

Opening one of them loads its history, but the composer is disabled with the placeholder “会话不可用”. The session then disappears from the sidebar, and it does not appear under Archive. Restarting DSH restores the three entries; opening any of them removes it again.

Rolling back to 0.2.1-rc.5 fixes it: the same sessions stay in the sidebar after opening and the composer remains enabled. No session data was lost.

Steps to reproduce

1. Start on 0.2.1-rc.5 with at least one cold/older session that has real history.
2. Upgrade to 0.2.2-rc.1 and restart the app.
3. Open that session from the sidebar.
4. Its history is shown, but the composer says 会话不可用; the session is removed from the sidebar.
5. Restart DSH: the entry returns.
6. Open it again: it disappears again.

In my case the affected sessions had 82, 292 and 6 turns. The 6-turn session also reproduced the disabled composer.

Evidence that the data is intact

• workspace.json still contains every affected session ID, and archivedSessionIds does not contain them.
• Each session.v4.jsonl.zstd is complete:
  • 82-turn session: 6,570,121 bytes
  • 292-turn session: 12,508,945 bytes
  • 6-turn session: 527,428 bytes
• A full Zstd frame scan found no torn/bad frames; the event sequence is continuous and ends with session/end-seed. No truncation.
• No crash log is generated when this happens.

Code observations (not a claimed root cause)

• dsh-api-session-controller/lib/types/list.js only drops records whose header.cwd is undefined; all affected headers have a valid cwd.
• dsh-session-persistence-jsonl/lib/index.js listArtifacts skips a generation when its header cannot be read; these headers are valid.
• dsh-api-index maps session/disposed to api-session/removed.
• dsh-client-ui-conversation InputBar computes approximately:
  disabled = removed || inert || !live || blocked !== undefined || parentOffline
  and falls back to placeholder.unavailable (会话不可用) when disabled.
• dsh-client-ui-workspace groupByWorkspace iterates the workspace IDs and skips entries absent from list.byId.

So the visible symptom is consistent with the client receiving/keeping removed for a disposed session, while the persisted workspace still contains the ID. The exact trigger for session/disposed is not known from the outside.

Expected

• A session present in workspace.json and not archived should stay visible after opening.
• Its composer should remain usable.
• Opening a session should not require a full app restart to bring it back.

Workaround

• Stay on 0.2.1-rc.5 for now; verify that a session stays in the sidebar after opening.
• If already on 0.2.2-rc.1, avoid opening affected sessions; restarting restores them temporarily.
• Back up %USERPROFILE%\.dsh\sessions, %USERPROFILE%\.dsh\storages\workspace.json, and the session projection cache before experimenting.

Additional observations (possibly separate issues)

1. Composer locked while the agent is running
   On 0.2.2-rc.1 I could not append a follow-up message while the agent was working. On 0.2.1-rc.5 the composer remains enabled during a running turn. This may be an intentional change, but if not, it is a separate UX regression worth confirming.

2. dsh-ops@0.4.4 is marked incompatible with 0.2.2-rc.1
   Its requirement is engines.dsh >=0.2.0-rc.2 <0.2.2-0. On 0.2.2-rc.1 it is skipped as incompatible, and the dsh-ops-mode-standard config entry is then reported as not found. This may be expected third-party lag, but because dsh-ops provides tools/systemPrompt, it can make the app look broken after an upgrade. Probably a separate plugin-compatibility issue.