DSH plugin Runtime Hoisting

DSH Plugin Runtime Hoisting: Preset Startup Failures

Author
DeepSeekAgent.io Editorial Team
Published
Updated

DeepSeek Harness plugins can add models, tools, and Agent Presets. When a plugin directory contains a second DSH runtime, however, an ordinary dependency conflict becomes two framework instances inside one process. A community case reports that installing @deepseek-ai/dsh-subagent-codex into a Desktop Profile caused pnpm's hoisted layout and automatic peer installation to place roughly 48 @deepseek-ai packages in the Profile. After a cold start, embedded Presets and plugins resolved different runtime copies, and Standard and Cordis Presets failed to mount.

Why it works until the next restart

During installation, the running process may already have loaded its core modules and Presets. Module caches are established, so the new Profile dependency tree does not replace existing references immediately.

A cold start performs module resolution again. The embedded application runtime and the hoisted Profile runtime are both visible. Entrypoints load different copies according to their paths, so the failure appears after restart and can affect both old and new Sessions.

That “works after install, fails after restart” signature narrows the investigation toward boot-time resolution, module caching, and plugin directory layout instead of ordinary Preset configuration.

Why two runtimes cannot behave as one

DSH scopes, contexts, registries, and identity checks rely on module-level state. Even when the package versions match, two physical module instances have different JavaScript object identity and separate singletons.

The reported failures include:

  • persona-prefix already registered, indicating duplicate initialization across runtimes;
  • missing scoped Preset Context for tool-subagent model selection settings, where an object created under runtime A is interpreted under runtime B.

The issue therefore goes beyond API-shape compatibility. A duplicate copy of the same version can split scope identity. Core framework runtime packages should be host-provided peers, not copied into a plugin directory.

Confirming a hoisting conflict

Preserve the Profile and inspect it read-only:

  1. record the plugin and exact version installed before the failure;
  2. check whether the Profile suddenly contains a large node_modules/@deepseek-ai runtime tree;
  3. compare real paths and versions for embedded and Profile dsh-* packages;
  4. use stack traces to identify where Scope, Preset, and Context modules resolved;
  5. reproduce a cold start with a clean Profile to separate dependency failure from Session data.

Moving the hoisted core runtime out of resolution can restore startup temporarily, but the next plugin operation may recreate it. That is useful for confirmation and recovery, not as a durable fix.

Packaging and installer requirements

Plugin packages should declare host runtime dependencies as peers and avoid shipping a locked copy of the complete DSH graph. The installer should also:

  • detect plans that would materialize a second core runtime;
  • block or isolate automatic hoisting of core @deepseek-ai/dsh-* packages;
  • verify that every plugin resolves one host runtime before Profile startup;
  • run a fresh-process Preset smoke test after installation;
  • roll back the dependency graph on failure.

“Installed successfully” is not sufficient acceptance. Standard, Cordis, existing Sessions, and the new plugin Preset must all mount after a Desktop restart.

Read this alongside the DSH Plugin Manager installation and rollback guide. That guide covers operations; this article explains why a framework runtime cannot be treated as an ordinary duplicated plugin dependency.

References

FAQ

Can two runtime copies conflict when their versions are identical?

Yes. Different module paths create different instances, splitting module-level singletons, scope identity, and context checks.

Is deleting the complete Profile the only recovery?

No. Back up first, identify the hoisted core packages, and quarantine the conflicting dependency tree. The durable correction belongs in the install plan or plugin declarations.

Why do old Sessions fail too?

Existing Sessions still mount Presets and contexts during startup. A shared boot-chain failure is not limited to the newly installed plugin.