Python SDK JSON-RPC runtime fails to initialize when @deepseek-ai/dsh-attachment-local is mounted

[06ED]

Platform:
macOS arm64

SDK:
0.1.1rc1

Runtime:
0.1.1rc1

Minimal cordis.yml:

- id: sdk-jsonrpc-server
  name: '@deepseek-ai/dsh-sdk-jsonrpc-server'

- id: llm
  name: '@deepseek-ai/dsh-llm-pi-ai'
  config:
    providers:
      alibaba:
        displayName: Alibaba
        api: openai-completions
        baseURL: https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1
        apiKeyEnv: DASHSCOPE_API_KEY
        models:
          - id: qwen3.7-plus
            contextWindow: 1000000
            input: [text, image]

- id: attachment-local
  name: '@deepseek-ai/dsh-attachment-local'
  config:
    dshHome: /tmp/dsh-test-home

- id: agent-spine
  name: '@deepseek-ai/dsh-agent-spine-demo'
  config:
    includeHarnessIdentity: false
    includeRuntimeContext: false
    workspaceContext: false
    skills:
      enabled: false
    toolBash: false
    toolJobs: false

- id: sessions
  name: '@deepseek-ai/dsh-session-persistence-jsonl'
  config:
    root: /tmp/dsh-test-sessions

[06ED]

Thanks — I narrowed it down further.

I tested the suggestions above, including using a clean writable directory under /tmp and reducing the Cordis config to a minimal reproduction.

The actual error is:

ERR_MODULE_NOT_FOUND:
Cannot find package '@deepseek-ai/dsh-attachment-local'
imported from:
/snapshot/deepseek-harness/python/sdk-runtime/src/deepseek_harness_runtime/runtime/node/node_modules/@deepseek-ai/cordis-plugin-loader/lib/index.js

Minimal config:

- id: sdk-jsonrpc-server
  name: '@deepseek-ai/dsh-sdk-jsonrpc-server'

- id: attachment-local
  name: '@deepseek-ai/dsh-attachment-local'
  config:
    dshHome: /tmp/dsh-test-home

The interesting part is that python/sdk-runtime/package.json appears to include @deepseek-ai/dsh-attachment, but not @deepseek-ai/dsh-attachment-local.

Since the Python SDK uses the bundled JSON-RPC runtime and resolves bare plugin package names from that bundled runtime, it looks like @deepseek-ai/dsh-attachment-local may simply be missing from the Python SDK runtime package/deploy closure.

[argszero]

Verified against rc.2 — the ERR_MODULE_NOT_FOUND is a snapshot-bundling dependency gap, and the fix is one line in python/sdk-runtime/package.json.

Root cause: the runtime package manifest omits a plugin the composition mounts

The /snapshot/... path in your trace is the dsh-jsonrpc-agent-pkg bundler snapshot (the pkg-style closure built from python/sdk-runtime/package.json's declared dependencies). Two verified facts in rc.2:

1. @deepseek-ai/dsh-attachment-local is not declared in python/sdk-runtime/package.json — a grep across the manifest finds zero references, while the sibling core package @deepseek-ai/dsh-attachment IS declared.
2. The composition that needs it comes from the base bundle: packages/bundle/base/cordis.patch.yml:106-107 mounts id: attachment-local, name: '@deepseek-ai/dsh-attachment-local', and packages/bundle/base/package.json correctly declares the package as a dependency. The Python runtime's own cordis.yml (python/sdk-runtime/src/deepseek_harness_runtime/runtime/cordis.yml) doesn't list it directly, but the runtime is built over the same composition family, so the plugin loader resolves the name: reference by import()ing the package at boot — and in the snapshot that package was never included.

This is the exact class the repo's manifest convention guards against — every plugin named in a cordis composition must appear in the resolver package's dependencies (the verify-cordis-config gate enforces it for the JS packages; the Python runtime's package.json is the resolver manifest for the bundled runtime and slipped through). The JS-side sibling reports of the same gap are #4339 (global install → "Cannot find package") and the packaging family around the dsh-tools snapshot.

Fix

Add the missing declaration to python/sdk-runtime/package.json:

"@deepseek-ai/dsh-attachment-local": "workspace:^",

next to the existing "@deepseek-ai/dsh-attachment": "workspace:^". That puts the package into the snapshot closure, and the loader resolves it at boot. (If the runtime is also meant to be deployable from a published registry, the same entry pins the registry range — check how the other workspace:^ deps are handled in the release build.)

If you want to confirm the chain before patching: run the same bundling with --no-snapshot (or unpack the snapshot) and check that node_modules/@deepseek-ai/dsh-attachment-local is absent while dsh-attachment is present — that absence is the whole bug.

[Mide69]

Confirmed this is still live on current master, not just rc.2. Grepped python/sdk-runtime/package.json directly:

only @deepseek-ai/dsh-attachment is declared, no dsh-attachment-local entry anywhere in the file. Matches argszero's finding exactly, so the fix (adding the workspace:^ line) is still needed as of now, this hasn't been patched yet.

[PerryLink]

Verified on master (c291e79): the diagnosis in the thread (argszero) is correct and the gap is still open.

• The base composition mounts the plugin and declares it:
  packages/bundle/base/cordis.patch.yml:118-119 (- id: attachment-local, name: '@deepseek-ai/dsh-attachment-local')
  packages/bundle/base/package.json:42 ("@deepseek-ai/dsh-attachment-local": "workspace:^")
• But the Python SDK's bundled-runtime manifest still only declares the sibling core package:
  python/sdk-runtime/package.json:23 ("@deepseek-ai/dsh-attachment": "workspace:^") — no dsh-attachment-local entry.
  The pkg-style snapshot is built from this manifest, so the loader's bare-name import fails at boot with the exact
  ERR_MODULE_NOT_FOUND ... /snapshot/.../cordis-plugin-loader/lib/index.js trace you captured.

Fix (one line, still needed): add "@deepseek-ai/dsh-attachment-local": "workspace:^" next to the existing
dsh-attachment entry in python/sdk-runtime/package.json, then rebuild the bundled runtime so the package lands in the
snapshot closure.

Workaround until then: if you don't need attachment storage in your SDK composition, don't mount attachment-local
in the runtime's cordis.yml (the base bundle mounts it by default — use a minimal SDK composition that omits the row,
or keep your own cordis.yml without it). The same manifest convention already guards the JS packages via
verify-cordis-config; the Python runtime's package.json is the resolver manifest that slipped through.