Bug: session resume fails — "agent-presets: refusing to compose an unscoped context" after upgrade

[bb6894]

Bug Report: Session resume fails — "agent-presets: refusing to compose an unscoped context"

Repository: deepseek-ai/deepseek-harness
Severity: High (blocks resuming existing sessions → cannot continue past conversations)
Environment:

• DeepSeek Harness dsh, v0.1 developer preview (installed via npx @deepseek-ai/dsh web)
• OS: Windows 11 (x64)
• Session data: ~/.dsh/sessions/<encoded-cwd>/<session-id>/session.jsonl.zstd (zstd-compressed JSONL)
• Session header records "agentPreset": "standard"

Symptom

Opening an existing session (clicking it in the sidebar) throws and the conversation cannot be resumed:

resume failed for session "session-ac5e9cef-e24f-4e5d-b034-accf78e98845": Error.

agent-presets: refusing to compose an unscoped context; the scope key is what joins an agent to its preset (internal)

Root cause (read from source — accurate)

The error string is thrown verbatim in @deepseek-ai/dsh-agent-presets lib/index.js:

// AgentPresets.mount(agentCtx, id)
const agentKey = scopeOf(agentCtx);
if (agentKey === void 0) throw new Error("agent-presets: refusing to compose an unscoped context; the scope key is what joins an agent to its preset");
// ...and identically in composeFrom(agentCtx, parentCtx)

i.e. when the session is rebuilt on resume, the agent factory's setup(agentCtx) calls agentPresets.mount(agentCtx, id) (or composeFrom), but scopeOf(agentCtx) is undefined at that point — the agent's scope context is not established before the preset join in the resume path. The session header's agentPreset string value ("standard" / "code") is NOT the cause; the error is about the agent's scope, not the preset id. Editing the header string does not fix it (verified: changing "standard" → "code" leaves the error unchanged, because the agent scope is still missing).

The session was created by an earlier build where the resume path set up the agent scope correctly; after upgrading dsh, the resume path no longer establishes the scope before the preset join, so every legacy session fails to resume. This is exactly the kind of breaking change the README warns about, but it should fail gracefully (or migrate) rather than throwing an internal invariant that blanks the whole resume.

Steps to reproduce

1. With an older dsh build, create a session (any preset) and chat a few turns.
2. Upgrade dsh to a newer build.
3. Re-open the client, click the old session to resume it.
4. Observe the error; the session does not open. (All legacy sessions are affected, not just one.)

Expected behavior

Legacy sessions resume normally after an upgrade, or fail with a user-facing message — not an internal invariant panic that makes the conversation unopenable.

Workaround (verified, data-safe)

The session log is intact; the conversation can be recovered by extracting it from the zstd JSONL into a readable transcript. Example (Python, using zstandard):

import zstandard, json
p = r"~/.dsh/sessions/<encoded-cwd>/<session-id>/session.jsonl.zstd"
with open(p, "rb") as f:
    for ln in zstandard.ZstdDecompressor().stream_reader(f).read().decode().split("\n"):
        if ln.strip():
            e = json.loads(ln)  # events: user/message, assistant/message, tool/call, tool/result, turn/start, turn/end ...

What does NOT help: editing the header's agentPreset value. The fix must be in the resume/agent-scope path.

Suggested fix

Before agentPresets.mount(agentCtx, id) runs in the resume code path, ensure the agent's scope context is initialized (scopeOf(agentCtx) is defined) the same way it is for a freshly created session. Alternatively, add a session-format migration / guard so a missing scope during resume is tolerated or synthesized, and the failure is surfaced as a recoverable error rather than an internal panic.

Notes

• The header agentPreset is a plain string ("standard"); the four shipped presets are standard, code, minimal, creator. The error is independent of which id is stored.
• I observed this while helping a user recover; re-compressing the .zstd with a different zstd frame also made the file unreadable by the client (separate footgun) — prefer restoring the original bytes rather than re-compressing session files.