DSH v0.2.1-rc.2 Invisible Sessions: Diagnosis & Recovery

If historical sessions disappear from the sidebar after upgrading to DeepSeek Harness v0.2.1-rc.2, do not equate an empty list with deleted data. Before DSH can display a session, it reads the persisted files, validates a session header, and associates the record with a workspace. A rejection at any layer can make the on-disk sessions and the visible list disagree.

A community investigation published on October 20, 2026 identified several distinct paths. The initial report showed that retired sandboxMode or approvalPolicy fields can make a session header throw while the listing path tolerates only selected error classes. Subsequent source and release-history review corrected an important assumption: no public DSH release wrote those fields, so affected headers are more likely to come from a short-lived development or nightly build. For ordinary upgrade cases, workspace ownership, duplicate session IDs, and path matching also require inspection. They cannot all be reduced to one “bad field.”

How the session list is assembled

DSH does not display a session from a directory name alone. At least three layers participate:

1. Persistence files: the JSONL or compressed session records still exist.
2. Session header: the current reader accepts the version, ID, working directory, and other header fields.
3. Workspace registry: the decoded session can be associated with a registered workspace in the expected order.

It is therefore possible for files to remain intact while the UI shows nothing. If the session directory itself is absent, however, the problem belongs to backup, migration, disk, or cleanup recovery rather than list filtering.

Narrow the fault from the symptom

The first question is whether the data exists; only then should the investigation ask why the list rejected it. Bulk-moving, renaming, or deleting directories under .dsh can turn a diagnosable index problem into real data loss.

Why a retired header field can affect the whole list

The community report localized an assertNoRetiredHeaderFields check in the v0.2.1-rc.2 artifact. A header containing sandboxMode or approvalPolicy throws a plain Error, while the surrounding list path treats only selected unsupported-format and corruption errors as record-local failures.

One rejected header can consequently interrupt a higher-level listing operation instead of merely marking itself unavailable. The same header is also read by list() and stat(). Teaching only the list to skip the record could turn “nothing is visible” into “the item is visible but cannot open.” A durable repair should represent a rejected generation as an explicit outcome shared by listing, inspection, opening, and recovery.

This trigger is not the root cause of every rc.2 report. Release-history review in the same discussion found that public releases did not write those retired fields. Users upgrading from public builds must still inspect workspace and duplicate-ID paths.

Workspace paths require precise diagnosis

The workspace registry affects project ownership, but a missing original directory is not automatically filtered. rc.2 already contains logic that preserves ownership for some previously accounted sessions when their recorded absolute path is temporarily absent.

The relevant questions are more specific:

• Does the registry record the intended workspace?
• Does the session header cwd resolve to the same canonical location?
• Did a Windows drive letter, path case, symlink, or junction change matching?
• Does the same session ID appear in multiple storage buckets?
• Is the path absent but tolerated, or present while resolving to a different directory?

That is why a recovery guide cannot responsibly prescribe one universal command such as recreating a directory or stripping a field.

A safe diagnostic order

1. Copy the complete DSH data directory, preserving timestamps and layout. Do not experiment on the only copy.
2. Record the version, channel, OS, and prior version. Nightly, development, and public release histories differ.
3. Confirm that session files exist and whether the impact covers every workspace or one workspace.
4. Inspect headers and duplicate IDs read-only. Produce a report before isolating a record.
5. Compare the workspace registry with real paths, especially Windows case, drive, and link targets.
6. Test one minimal repair on a copy. After restart, verify list, open, continue, and compact behavior together.
7. Preserve before-and-after evidence so upstream can distinguish a reader, registry, or migration failure.

If a suspicious session must be isolated, move it into a separate backup location rather than deleting it. Header edits also belong on a copy, with the JSONL first-line structure, compression format, and multi-generation relationship preserved. Text replacement inside a compressed record can destroy the complete session.

What the product should do

A resilient session system should not let one rejected record erase the entire visible list. Better behavior includes:

• continuing to load unaffected sessions;
• displaying that a record requires recovery instead of hiding it;
• sharing error classification across list(), stat(), open, and recovery;
• distinguishing incompatible headers, duplicate IDs, registry mismatches, and damaged files;
• providing read-only diagnostics and reversible repairs.

The incident also illustrates the testing gap described by HarnessTester. Session tests must cover one malformed record, legacy headers, duplicate IDs, changed paths, and partial migrations—not only clean happy paths.

References

• Community investigation of invisible sessions on v0.2.1-rc.2
• DeepSeek Harness v0.2.1-rc.2 release
• Session header validation source
• Workspace subsystem documentation
• DeepSeek Harness v0.2.1-rc.2 update

FAQ

Does an empty history mean the session content is gone?

Not necessarily. Confirm the files first. Header parsing, duplicate IDs, and workspace ownership can hide intact records.

Should I delete the session directory that appears to cause the problem?

No. Back it up and test by isolation. Deletion converts a potentially recoverable indexing problem into irreversible loss.

Is this one confirmed v0.2.1-rc.2 bug?

No single cause covers every report. The repository discussion confirms several real paths and also corrects parts of the initial release-history and missing-directory analysis. Diagnose the actual files, headers, and registry.