Desktop host: plugin-visible ctx.sessions registry is empty (ctx.sessions.get returns undefined for live sessions)

[lhh010]

Summary

On the Desktop host (dsh-v0.2.0-rc.2, Windows), a client plugin's host half resolves ctx.sessions.get(sessionId) to undefined for every session id — including sessions the same host is actively running. The identical plugin, profile composition, and dsh version work correctly on the Web host. This breaks any plugin that resolves the session's workspace cwd through the sessions service; in our case the paste/attachment plugin can no longer upload files on Desktop.

Environment

• DeepSeek Harness Desktop 0.2.0-rc.2 (Windows, installed from deepseek.com/harness), built-in runtime
• Profile composition identical on both hosts: bundles dsh-base + dsh-web-app (+ our plugins), plugins installed via pnpm link: to local directories
• Control: Web host = @deepseek-ai/dsh@0.2.0-rc.2 via nvm4w npm, same profile bundles, same plugin tree

Repro (host-side, no UI needed)

The plugin registers an HTTP route through ctx.webServer.register({ kind: 'prefix', path: '/dsh-paste-input/v1', ... }). Against the Desktop host (127.0.0.1:19387, unauthenticated probes):

GET  /dsh-paste-input/v1/latest  -> 200 {"ok":true,"plugin":"dsh-paste-input","dshVersion":null}   # host half IS mounted
POST /dsh-paste-input/v1/batches -> 400 "live session not found: <sessionId>"                      # for EVERY id

The route handler starts with the canonical resolution:

const session = ctx.sessions.get(sessionId)   // undefined on Desktop, found on Web
if (session === undefined) throw new Error(`live session not found: ${sessionId}`)
const cwd = session.header.cwd

Tested ids: (a) a session actively running on the Desktop host at that moment (its session.v4.jsonl.zstd was being appended under ~/.dsh/sessions/<workspace>/session-<id>/), and (b) another persisted session — both undefined. The plugin's cordis inject: ['webServer', 'loader', 'sessions'] resolves (the plugin activates and serves), so a service named sessions exists — but its live-session registry appears empty from a plugin fiber on the Desktop host.

On the Web host (port 3080, same machine, same rc.2), the exact same probe flow completes: batch -> file PUT -> commit all succeed and land in <workspace>/.dsh/tmp/attachments/.

User-visible symptom

Pasting files in a Desktop conversation: chips render but resolve "unavailable" (no file was ever written), and sending fails. On Web the same paste flow works end-to-end.

Second, possibly related divergence: reduced child PATH on Desktop

Tool subprocesses spawned on the Desktop host see a minimal PATH — e.g. pwsh is not resolvable (spawnSync pwsh ENOENT) while System32 tools are. The rc.2 release notes fix the missing login-shell environment for macOS/Linux graphical launches; Windows Desktop may still need the equivalent.

Suspicion (unverified)

The Desktop runner (dsh-desktop-host → runProfile) may boot the composition with a different cordis fiber/isolate layout than the CLI app-boot, so the sessions service a plugin resolves is not the live registry the agent runtime populates — possibly a different provider or an isolate-scoped instance.

Happy to run any further probes against the running Desktop host. The plugin involved is open-source (lhh010/dsh-paste-input) if the source helps.

[lhh010]

Also filed in the beta feedback tracker: dsh-external/issues#655 (https://github.com/dsh-external/issues/issues/655). The PATH finding there cross-references #653 (desktop not inheriting zsh/bash environment variables) as the same family.

[lhh010]

Update: plugin-side workaround confirmed working (no host changes needed).

We shipped a fix in the affected plugin (dsh-paste-input v0.2.6) that works around both Desktop divergences without touching dsh:

1. Session resolution — when ctx.sessions.get(sessionId) misses, resolve the workspace through ctx.get('workspaceRegistry'): the registry maps header-validated sessionIds to canonical workspace paths, so the cwd is still derived entirely server-side (no client-supplied paths).
2. Upload transport — the dsh-app:// forwarding also mangles binary PUT bodies: with a Blob body, the forwarded request's declared Content-Length (e.g. 16046) no longer matches the bytes the host receives, so our size validation rejects the upload ("Content-Length must equal declared file size"). This did not happen on Web. The plugin now ships a base64 JSON transport for the Desktop origin (POST /batches/<id>/files/<n>/base64) while keeping the binary PUT fast path on Web.

Both verified end-to-end on Desktop 0.2.0-rc.2 (Windows): paste → upload → commit → file lands under <workspace>/.dsh/tmp/attachments/, send succeeds.

So for other plugin authors hitting this: workspaceRegistry + a text-safe (base64/JSON) request body are viable Desktop workarounds until the host-side issues are fixed. The host-side findings above still stand as bugs worth fixing (empty plugin-visible sessions registry; binary body corruption through the protocol forwarding).