[Bug] Tool call fails on Windows: Cannot read properties of undefined (reading 'prepare') — TOOL_RUNTIME_SCHEDULER unimplemented, ptc-runtime absent from all bundles

[wsjwyatt]

Environment

• OS: Windows 11 (win32, x64)
• Node.js: v24.12.0
• pnpm: 11.7.0 (pinned via packageManager in root package.json)
• dsh version: dsh-v0.1.6-alpha.2 (tag dsh-v0.1.6-alpha.2, commit ddefc45fbc)
• Install method: source build (git clone → pnpm install → pnpm run build)
• Profile: web (via pnpm dsh web)

Steps to reproduce

1. Fresh clone at tag dsh-v0.1.6-alpha.2
2. pnpm install
3. pnpm run build
4. pnpm dsh web — startup succeeds, zero failed plugins
5. Open a new session, send any prompt that triggers a tool call (e.g. a Glob file search)

Actual behavior

Every tool call fails with two cascading errors:

Cannot read properties of undefined (reading 'prepare')

DeepSeek Messages tool calls need immediate results   (400 INVALID_REQUEST)

The UI shows "本轮运行失败" (turn failed) with UNKNOWN / INVALID_REQUEST status tags.

Root cause analysis

The failure originates at:

// packages/core/agent-loop/src/tool-calls.ts:170
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

Grepping the whole repo, TOOL_RUNTIME_SCHEDULER appears only as a declaration — there is no implementation assigned to it anywhere:

packages/core/tools/src/index.ts:448   export interface ToolRuntimeScheduler { ... }
packages/core/tools/src/index.ts:463   export const TOOL_RUNTIME_SCHEDULER: unique symbol
packages/core/tools/src/index.ts:798   readonly [TOOL_RUNTIME_SCHEDULER]: ToolRuntimeScheduler
packages/core/tools/src/ptc.ts:550     const scheduler = registry[TOOL_RUNTIME_SCHEDULER]   // consumer
packages/core/agent-loop/src/tool-calls.ts:153,154,170,174  // consumers
packages/extensions/tool-cordis/src/api-catalog.ts:6797,6800,6801  // API doc catalog only

So ctx.tools[TOOL_RUNTIME_SCHEDULER] resolves to undefined, and .prepare(...) throws immediately.

Because the tool never executes, no tool result is produced. DeepSeek's API strictly requires each assistant.tool_calls entry to be followed by a matching tool message, so the next request is rejected with 400 INVALID_REQUEST / tool calls need immediate results. The second error is a consequence of the first, not an independent issue.

Suspected missing provider (needs maintainer confirmation)

packages/ptc-runtime/ exists in the tree and is the most likely provider of this scheduler. However:

Select-String -Path D:\dsh-fresh\packages\bundle\*\*\package.json -Pattern "ptc-runtime"
# → no matches

ptc-runtime does not appear in the package.json of any of the six bundles:
packages/bundle/{base, web-app, headless, acp-app, sdk-app, sdk-minimal}.

I am not certain that ptc-runtime is the intended provider — this is my inference from the package name. If another package is supposed to register TOOL_RUNTIME_SCHEDULER, please correct me.

Important: startup is clean

This is not a dependency or build problem. I verified:

• pnpm run build completes successfully (all lib/ produced)
• pnpm dsh web starts with zero failed plugins (no new Failed plugins entry in .dsh/logs/startup-*.log)

The failure happens at runtime, during tool dispatch, not at plugin activation.

Things already ruled out

• ✅ Corrupted node_modules — fully removed (\\?\ prefix to bypass MAX_PATH) and reinstalled from scratch; also cleared the pnpm store
• ✅ Wrong build entry — the correct entry is pnpm run build (tsx scripts/build.ts); note that packages/*/* have no build script, so pnpm -r build is a no-op for them
• ✅ Port conflict (EADDRINUSE on 3080) — killed stale node processes
• ✅ Poisoned session transcript — reproduced in a brand-new session
• ✅ Platform-specific native addon — @deepseek-ai/node-addon-landlock-run (landlock) is Linux-only, but sandbox-local failing is non-blocking and unrelated to this stack

Impact

Every tool call fails, so the agent cannot do anything requiring tools on Windows. The session transcript also becomes permanently poisoned once an unpaired tool_call is written: all subsequent messages in that session return the same 400, and a restart does not repair it (the broken transcript is reloaded as-is).

Questions for maintainers

1. Which package is supposed to provide the TOOL_RUNTIME_SCHEDULER implementation?
2. Should ptc-runtime be included in the web / headless bundles? If so, its absence looks like a packaging omission.
3. Is there a supported Windows path here, or is web profile unsupported on win32 at this version?
4. Can the runtime emit a clear error (e.g. "tool runtime scheduler not registered") instead of a raw undefined dereference?

Additional context

Happy to provide the full startup diagnostic log (~/.dsh/logs/startup-*.log) after redacting credentials, plus a screenshot of the failing turn.

[PerryLink]

The scheduler is implemented — your grep pattern missed it, and that is the whole conclusion that needs correcting. Everything else you wrote is right and the fix list at the end of this reply is short.

The implementation is a computed-property class field

packages/core/tools/src/index.ts:789 declares export class ToolRuntime extends Service, which is the tools service (packages/core/tools/src/index.ts:829 is super(ctx, 'tools')). It carries the scheduler as a computed class field:

// packages/core/tools/src/index.ts:797-803
/** Internal staged view consumed by `dsh-agent-loop`'s parallel scheduler. */
readonly [TOOL_RUNTIME_SCHEDULER]: ToolRuntimeScheduler = {
  prepare: exec => this.prepareScheduledExecution(exec),
  dispatch: exec => this.dispatchScheduledExecution(exec),
  finalize: (exec, result) => this.finalizeScheduledExecution(exec, result),
  finish: (exec, result) => this.finishScheduledExecution(exec, result),
}

A search for TOOL_RUNTIME_SCHEDULER: or TOOL_RUNTIME_SCHEDULER] finds it; a search for the symbol alone, or for a separate provider package that assigns it, does not, because there is no such package and never was. packages/core/tools/src/ptc.ts:550 reads registry[TOOL_RUNTIME_SCHEDULER] from an already-registered ToolRuntime — it is a consumer too, not a provider. So the scheduler is registered by the tools service itself, in-process, during plugin activation. Nothing is missing from any bundle.

ptc-runtime is not the provider and not the problem. Your own grep looking for ptc-runtime in bundle manifests did not match because the package is named @deepseek-ai/dsh-ptc-runtime-node, and it is in fact declared at packages/bundle/base/package.json:123. Its description is "Sandboxed Node process implementation of the DeepSeek Harness PTC execution capability" — it implements the ctx.ptcRuntime seam, which is unrelated to the scheduler symbol.

Why ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined anyway

Two module instances of @deepseek-ai/dsh-tools exist in one process, and the symbol is module-local at packages/core/tools/src/index.ts:463:

export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')

Symbol(...) is not Symbol.for(...), so each instance of the module creates a different symbol. The two planes, both present in a built source checkout:

• tsx plane — dsh is node --import tsx/esm apps/cli/src/bin.ts (package.json:189), and tsconfig.base.json maps "@deepseek-ai/dsh-tools": ["./packages/core/tools/src"] (tsconfig.base.json:484). dsh-agent-loop reaches this plane for import { TOOL_RUNTIME_SCHEDULER } from '@deepseek-ai/dsh-tools' (packages/core/agent-loop/src/tool-calls.ts:17).
• Node plane — the profile's fallback link $DSH_HOME/profiles/node_modules/@deepseek-ai/dsh-tools points at the package directory (packages/boot/app-boot/src/profile.ts:668, ensureSymlink(link, entry.packageDir)), and Node then follows the package's own exports field: "default": "./lib/index.js" (packages/core/tools/package.json:19). The plugins the profile mounts resolve through that link.

Both symbol instances are visible without running anything. Refresh lib/ first if you have edited since your last build, then:

Select-String -Path packages\core\tools\src\index.ts -Pattern 'Symbol\(.' -SimpleMatch   # :463
Select-String -Path packages\core\tools\lib\index.js  -Pattern 'Symbol\(.' -SimpleMatch   # :2526

lib/ is the compiled copy of the same line (packages/core/tools/lib/index.js:2526, and the class field at :2674). Two files, two Symbol() calls, two keys. ToolRuntime writes its scheduler under the lib/ symbol; tool-calls.ts reads under the src/ symbol; the read is undefined, and tool-calls.ts:170 throws on .prepare.

Why this appears now. apps/cli/src/profile-boot.ts:263 reads const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime' — commit 9ddef327a40dc8d128a1d8b912fc17677ddf0ed8 flipped that default from 'link' to 'runtime'; the last tag that still ships ?? 'link' is dsh-v0.1.6-alpha.1 (0a15e36e7f, same line at apps/cli/src/profile-boot.ts:305), which is why that release does not show this. dsh-v0.1.5-rc.2 (fb2c4b9e69) does not show it either, but for a different reason: it predates the whole resolutionMode feature. There is no CLI flag or env var to override it: apps/cli/src/args.ts defines no resolution option and apps/cli/src/bin.ts:38 calls runProfile without one.

One thing this is not: the resolver does not itself load two copies of dsh-tools. Both resolution modes consume the same generation plan and dual mode asserts the disk result equals the generation route (.agents/notes/implemented/architecture/2026-09-09-profile-resolution-generations.md:75). The split is between the bare specifier tsx maps to src/ and the package-relative entry (lib/) that the profile-installed plugin resolution reaches.

Your cascade diagnosis is correct

packages/core/agent-loop/src/tool-calls.ts:170 is the throw site, exactly as you said, and the session poisoning follows from it: startCall appends tool/call at :168 and only produces results via commitReady → appendToolResult at :156, so a throw at :170 leaves the assistant message's tool calls with no result. The turn then closes with turn/end carrying { kind: 'error' }, and because the turn is closed, interruptedTurnClosers returns early (packages/core/session/src/repair.ts:82) and synthesizes no repair — which is why a restart reloads the same broken transcript, as you observed. The second error is a consequence of the first, as you concluded.

What to do

1. Run the built entry instead of the tsx entry. Once pnpm run build has produced artifacts (yours has), node apps/cli/lib/bin.js web puts every resolution on lib/, so one symbol is shared. This needs no source edit.
2. Or revert the default at apps/cli/src/profile-boot.ts:263 back to options.resolutionMode ?? 'link'. No rebuild is needed for pnpm dsh, and this is what dsh-v0.1.6-alpha.1 shipped — but be aware it fails the committed test at apps/cli/tests/resolved-profile-boot.spec.ts:94, which pins { selection: 'default', options: {}, mode: 'runtime' }, and it is overwritten on upgrade.
3. Or roll back to dsh-v0.1.6-alpha.1 (0a15e36e7f) — the closest tag that still defaults to 'link' — or further to dsh-v0.1.5-rc.2 (fb2c4b9e69), which predates the feature.

A durable code fix would make the key process-global, i.e. Symbol.for('@deepseek-ai/dsh-tools.scheduler') at packages/core/tools/src/index.ts:463, so duplicate module instances agree on the key. I have not verified that against a running build myself.

To answer your four questions directly: (1) ToolRuntime in @deepseek-ai/dsh-tools, packages/core/tools/src/index.ts:798; (2) no — ptc-runtime is not supposed to provide it, and nothing is missing from the bundles; (3) yes, the web profile is fine on win32 — the trigger is the resolution default, not the platform, and macOS reporters hit the same thing; (4) agreed that a named error would be better than a raw undefined dereference, but I cannot speak to whether that will change.