Web UI: creating/resuming any agent fails with 'refusing to compose an unscoped context' (rc.6 & rc.7) — root cause + one-line fix

[kongminOS]

Summary

On DSH 0.1.0-rc.6 and rc.7, in the GUI (web UI), creating a new session, resuming an existing one, or switching models can fail with:

agent-presets: refusing to compose an unscoped context

This happens when an installation ends up with two physical copies of @deepseek-ai/dsh-scope loaded into one process (for example, the engine's own node_modules and a separately-managed profile tree's node_modules each resolve their own copy). The scope identity tag is a module-local symbol, and the two copies do not share it — a context minted through one copy is invisible to the other, so the agent is seen as unscoped.

This is rooted in the engine itself and is still present in rc.6/rc.7. Below is the root cause plus a one-line fix, along with a fork containing the change.

Repro (3 steps, ~30 seconds)

1. Install DSH rc.6 or rc.7.

2. Start the web UI (dsh web).

3. Click "New session" (or resume an existing session / switch model) → the error appears.

The failure depends on which copy of dsh-scope minted the scope context versus which one reads it, so it may be intermittent across setups.

Root cause

packages/core/scope/src/index.ts:

const kScope = Symbol('dsh.scope')

Symbol() returns a new unique symbol on every call. When the host and the agent-presets plugin each resolve @deepseek-ai/dsh-scope to a different installed copy, each copy re-executes this line and gets an unrelated symbol. The scope tag written under one copy's symbol (createScope → fiber.ctx.extend({ [kScope]: key })) cannot be read by the other copy's scopeOf(ctx), so the context looks unscoped to the reader.

The monorepo itself uses pnpm workspaces, which hoists dsh-scope to a single copy, so this usually does not surface internally — it shows up in installations that load two distinct copies.

Fix (one line)

const kScope = Symbol.for('dsh.scope')

Symbol.for reads/writes the same global-registry entry regardless of which module copy executes it, so tags written by any copy are read back correctly by any other. Single-copy behavior is unchanged. Symbol.for is already the pattern used in this repo for cross-instance identity (e.g. Schemastery's Symbol.for('schemastery')).

We verified this: editing the installed copies (node_modules/@deepseek-ai/dsh-scope/lib/index.js) or the source at packages/core/scope/src/index.ts from Symbol('dsh.scope') to Symbol.for('dsh.scope') makes session create/resume/model-switch succeed immediately, no rebuild.

Fix ready on a fork

We prepared the change as a branch you can review or cherry-pick:

• Fork: kongminOS/deepseek-harness

• Branch: fix/dsh-scope-symbol-for

• Commit: fix(scope): use Symbol.for so the scope tag survives duplicate package copies

• Diff: one line in packages/core/scope/src/index.ts

Not just a diagnosis — a reproducible fix branch. Happy to open a PR if the issue tracker / pull-request channel reopens.

Also worth noting

While on rc.7, another engine-level item paired with this: DeepSeek API error (HTTP 404) when llm-deepseek.baseURL in ~/.dsh/settings.yaml is set to https://api.deepseek.com/anthropic (Anthropic-compatible endpoint) — the OpenAI-format adapter calls /chat/completions, which the Anthropic path does not serve. Setting it to https://api.deepseek.com (or deleting the key) fixes it; settings.yaml hot-reloads.

More details on both are in the desktop-shell's Known Issues section: https://github.com/kongminOS/kongmin-dsh-desktop-shell#known-issues--fixes-dsh-engine-010-rc6--rc7

[Nerdless-ship-it]

Adding a September data point — this is still present on the latest release (@deepseek-ai/dsh@0.1.5-rc.1 / dsh-scope@0.1.5-rc.2 still ship const kScope = Symbol("dsh.scope")) — via a duplication path I haven't seen reported yet: the duplicate copies live inside the engine install tree itself.

Environment: Windows 11, Node v26.8.2, npm 12.0.2, launched via npx @deepseek-ai/dsh web.

After npm rewrote an existing npx install (npm cache clean → npx reinstalled the tree), 81 @deepseek-ai/* packages existed twice, byte-identical, same version:

• …/@deepseek-ai/dsh/node_modules/@deepseek-ai/*
• …/@deepseek-ai/dsh-base/node_modules/@deepseek-ai/*

(the duplicated set covers the dsh-agent peer family — dsh-scope, dsh-session, dsh-invariants, …)

Same failure as described: dsh-agent-loop resolves the dsh-base copy and mints the scope with its symbol; dsh-agent-presets resolves the dsh copy and reads with its symbol → scopeOf(agentCtx) === undefined → every session create/resume fails.

Also worth noting: a clean npm install of the same versions into an empty directory produces a flat, single-hoisted-copy tree (verified twice), so this surfaces to users as "it broke after a reinstall/upgrade" with no config change.

Workaround we verified end-to-end: make every duplicated package resolve to one realpath — replaced the nested copies with directory junctions pointing at a single copy. Create + resume succeed afterwards. But it must be reapplied after every npm re-layout — which is why a Symbol.for('dsh.scope') fix is the right level: it survives every layout that duplicates the module.