[Bug] @deepseek-ai/dsh-subagent-codex bundle fails to load in a profile — subagent_codex tool never registers (peer dependencies unresolvable)

[illyfhy]

Summary

The official @deepseek-ai/dsh-subagent-codex@0.2.1-rc.2 bundle installs and reports as enabled, but its provider and delegation tool never register — even after restarting the app. subagent_codex never appears, so the feature is completely unusable.

Root cause: when loaded from a profile's node_modules, the plugin cannot resolve its peer dependencies (host-internal packages such as @deepseek-ai/dsh-subagent, @deepseek-ai/dsh-timeout, @deepseek-ai/dsh-subprocess), so the module import fails and the provider is never registered.

Environment

• DSH desktop app, macOS (darwin-arm64)
• Profile directory: ~/.dsh/profiles/desktop
• pnpm 11.28.5, nodeLinker: hoisted, autoInstallPeers: false (from the profile's pnpm-workspace.yaml)
• Codex CLI 0.153.4 present and logged in (~/.codex/auth.json exists)

Steps to reproduce

1. In the Web/Desktop plugins page, enable Codex subagent → install succeeds (+ @deepseek-ai/dsh-subagent-codex 0.2.1-rc.2, 10 packages).
2. Restart the DSH app.
3. Observe the results.

Expected behavior

The bundle's two rows (subagent-codex provider + tool-subagent-codex tool) are registered, and the subagent_codex tool is exposed to agents.

Actual behavior

• list_bundles shows the bundle as enabled: true, installed: true, and it is present in package.json → dsh.profile.bundles (5th entry).
• But the live plugin list (201 entries) contains no include:subagent-codex / include:tool-subagent-codex.
• Config.listConfigs(name = "@deepseek-ai/dsh-subagent-codex") returns 0 entries.
• Config.listConfigs(name = "@deepseek-ai/dsh-tool-subagent") returns only the 2 inactive base rows (tool-subagent, tool-subagent-fork); the tool-subagent-codex row is absent.
• The agent's callable tool list has no subagent_codex.

Root cause analysis

1. The plugin declares these peerDependencies:
   @deepseek-ai/cordis, @deepseek-ai/dsh-llm, @deepseek-ai/dsh-session, @deepseek-ai/dsh-subagent, @deepseek-ai/dsh-subprocess, @deepseek-ai/dsh-timeout (all 0.2.1-rc.2 range).
2. The profile's pnpm-workspace.yaml has autoInstallPeers: false, so installation only installs the plugin's hard dependencies (dsh-brand, dsh-sdk-protocol, schemastery, dsh-tool-subagent, @openai/codex, …) — not the peer dependencies.
3. Those peer packages live inside the host app.asar's node_modules; a profile plugin using ESM import cannot resolve into the asar (the profile node_modules and the host are two separate directory trees).
4. Result — importing the plugin fails:

   Cannot find package '@deepseek-ai/dsh-timeout' imported from
   .../node_modules/@deepseek-ai/dsh-subagent-codex/lib/index.js
   

   Module load fails → provider never registers → the bundle's two insert rows never take effect.

Note: these peer versions are published on npm (@deepseek-ai/dsh-timeout@0.2.1-rc.2, @deepseek-ai/dsh-subagent@0.2.1-rc.2, …), so manually installing them is technically possible — but that is not a correct fix, because the provider must register into the host ctx.subagents singleton (registerProvider). Installing separate copies in the profile would create different module instances and register into the wrong registry.

Impact

• subagent_codex never appears; the official Codex delegation feature is completely unusable.
• The sibling official bundle @deepseek-ai/dsh-subagent-claude-code is likely affected by the same issue.

Suggested fixes (for the maintainers)

Any one of:

1. Host bridging — expose the host's internal @deepseek-ai/* packages as ambient modules to profile plugins (ESM import resolves to the host's real instances), preserving singleton semantics.
2. Install-time peer resolution — when the plugin-manager installs an official bundle, resolve its peers against the host's packages (alias to the host instances) rather than relying on the profile's autoInstallPeers.
3. Change availability — mark bundles that need host-internal peer packages as installation (host-installed) instead of profile, to avoid the resolution break across the two directory trees.

Additional (possibly orthogonal) observation

Even bypassing the plugin and running codex exec directly, it fails under the DSH workspace-write sandbox:

failed to initialize in-process app-server client: Operation not permitted (os error 1)

(Codex initialization needs to write PATH aliases / create its app-server, which exceeds the sandbox's writable scope.) It works after granting danger-full-access.

[PerryLink]

Your root cause is right, and it is structural.

The plugin declares host packages as peers

packages/subagent/subagent-codex/package.json:39-46:

"peerDependencies": {
  "@deepseek-ai/cordis": "workspace:~",
  "@deepseek-ai/dsh-llm": "workspace:*",
  "@deepseek-ai/dsh-session": "workspace:*",
  "@deepseek-ai/dsh-subagent": "workspace:*",
  "@deepseek-ai/dsh-subprocess": "workspace:*",
  "@deepseek-ai/dsh-timeout": "workspace:*"
}

And the profile never installs peers

packages/boot/app-boot/src/profile.ts:184-189 writes the profile's pnpm-workspace.yaml as:

nodeLinker: hoisted
autoInstallPeers: false

So pnpm install in ~/.dsh/profiles/desktop deliberately does not fetch those peers. Add the two: a plugin installed into the profile gets its peers nowhere, its dynamic import fails, and the tool never registers — which is exactly what you observed, and why restarting changes nothing.

The autoInstallPeers: false is not accidental either: with nodeLinker: hoisted, installing a peer would put a second copy of cordis (and friends) in the profile, and two cordis instances is a worse failure than a missing one. So "just turn peers back on" is not the fix.

What actually has to change

Either ship this plugin from the installation anchor instead of the profile (the anchor's node_modules has every peer, and resolveBundleDir already prefers it), or give the profile a resolution path to the installation's packages for host-internal names. The first matches how the in-box bundles already work.

Until then: subagent_codex cannot work from a profile install in this version, regardless of what the bundle list says.

Read-only source inspection at fcc0ad46; I did not run your install.