DeepSeek Harness new session shows old content: blank reuse

Click "new session" and you get a blank input page that looks perfectly normal; type "haha" and send it, and the screen first shows an image card generated with /image on October 20, with your new message appended after it. The UI is not rendering wrong — the new session was never created; it reused an old session treated as "blank" and seeded from it (#10889). Separate the three kinds of shell sessions first, then decide what to clear.

DeepSeek Harness: Signal 1: old content appears in a new session

If old events appear before session/end-seed, it is reuse; a genuinely blank session never has that event sitting in the middle.

1. Find the session log at ~/.dsh/sessions/<workspace>/<session-id>/session.v4.jsonl.zstd.
2. Decompress it and read the event order: in the community case seq 3 was a command/run from 10-20 and seq 4 was command/done.
3. Seq 5 was session/end-seed at 10-24 20:33 — that is "closing the old log as a seed".
4. Seq 6 was the new message agent/inbox/spliced "haha", and turn/start only began at seq 7.
5. The event timestamps are the evidence: one log containing two time ranges four days apart.

DSH plugin: Signal 2: the creation time is wrong

The session header's createdAt keeps the old value, so a "new session" shows a creation time from days ago; this is the most direct reuse clue.

1. Compare the creation time in the session list with the moment you clicked "new".
2. In another community case the new session showed 10-17 while the actual day was 10-24.
3. Those logs usually contain only three seed events: permission/preset, sandbox/mode, and approval/policy, with no turn/start and no end-seed.
4. In other words, the previous creation never finished, leaving a half-initialized record that was judged blank and reused.

DeepSeek Harness: Three shell types: why they count as blank forever

blank means "the folded prefix contains no turn", regardless of whether there is content, so all three types below stay in the candidate pool indefinitely.

Community measurement: an /image session and a session with only one user/message both show blank: true in sessionListMetadata. The check is written in the schema: "Whether the folded prefix contains no turn."

DSH Plugin: Signal 3: subagent model selection silently stops working

These sessions contain no subagent/model-selection-policy event, so the subagent tool carries no provider/model, while the settings page still says it only affects new sessions and the user has no way to notice.

1. Open the workspace config and confirm subagent-model-selection-settings has enabled: true and allowedModels.
2. Search the reused session for subagent/model-selection-policy; the event is absent.
3. Look at the tools array in request/header: subagent has only cwd, description, and prompt, with no provider, model, or reasoning_effort, and no list_subagent_models.
4. Compare a genuinely new session in the same workspace: the policy event appears at seq 3, subagent has the three extra parameters, and list_subagent_models is present.
5. The root cause is that tool-subagent decides new sessions with firstLiveSeq === 0; for a reused session restored from disk the first live sequence is 3 (4 after end-seed is filled in), never 0, so the policy is neither read nor written.
6. The policy is a one-time per-session snapshot: that healthy session snapshotted the 2 routes available then, while the current config already has 4.

DeepSeek Harness: Cleanup: find the shell sessions and move them out

There is one criterion: no turn/start in the log, but commands or user messages present.

1. Quit DSH completely so nothing writes while you clean.
2. Back up the whole ~/.dsh/sessions directory.
3. Decompress each session's session.v4.jsonl.zstd (a multi-frame zstd format, so decompress frame by frame).
4. Count turn/start occurrences: 0 with command/run or user/message present means a shell.
5. Move those directories outside the sessions root (do not delete them outright; move first and observe).
6. After restarting, create a session and confirm the input page is truly blank and the creation time is now.

One more thing to check: if a reused blank session fails log validation, creation fails outright instead of skipping it. The community hit SessionQueryError: stored session ... is corrupt ... session event at seq 4 lacks an identified message, caused by an older version's user/message event having no data.id while the current version requires one. Fix the log by hand or delete that session.

DSH plugin: Fix direction and today's workaround

Core needs to change the blank check: count only "header plus default init events" as blank, and re-read the log before reuse.

1. Redefine blank as "the log is empty": only a header plus permission/preset, sandbox/mode, and approval/policy qualify.
2. Or at least exclude sessions containing user/message or command/run from the candidate pool.
3. Re-read the log before reusing (refreshProjections() currently runs only on the restoreBlank branch, while ordinary creation uses a possibly stale cached hint).
4. When a "blank with content" is detected, create a new session instead of seeding the old log.
5. Make the create path tolerant of one bad session: skip it with a notice rather than letting one bad log block creation.
6. On the subagent side, change the freshness check to "no turn/start", or write the policy event once on the blank-reuse path.

One-minute self-check list

Spend a minute on three checks after every new session, and you can catch shell sessions before the bleed gets bad.

1. Does the creation time in the list match the moment you clicked new?
2. Is the input page completely blank, with no history cards and no leftover scroll position?
3. After the first message, does the log avoid an ordering where session/end-seed precedes your message?

If any of the three is off, move the candidate sessions out using the cleanup steps and create the session again.

Cautions

Trust the log over the blank-looking UI.

1. Do not assume "the UI is blank" means a new session. The real check lives in the log, not the UI.
2. Do not delete only the last one. There may be several shells; clear one and the next creation reuses another.
3. Do not ignore the creation time. It is a zero-cost self-check signal.
4. Back up before cleaning. Session logs hold history that cannot be recovered after a mistaken delete.
5. Recheck after upgrading. The community still reproduced it on rc.3, so do not assume a version change fixes it.

If your new sessions look normal and only occasionally an old image shows up, that is still this family — the candidate pool just happened to contain one shell.See DeepSeek Harness draft lost when switching a new session for the related case.