Zero-argument tool bindings always fail in PTC mode: "binding arguments must be lossless JSON" (root cause + suggested fix)

[rui08984-dot]

Environment

• DSH 0.1.2-rc.1, Windows 11, PTC preset (run_code code-runtime worker thread)
• Example binding provider: dsh-mnemon 0.4.7 — but any plugin exposing zero-parameter tools is affected

Repro

1. In PTC mode, call a zero-argument tool binding inside a run_code program, e.g. tools.mnemon_status() (mnemon_status declares no parameters).
2. The call deterministically rejects with: binding arguments must be lossless JSON.
3. The same tool called directly (not via run_code) works; tools with parameters called via run_code also work. Only zero-parameter bindings are affected — verified across two plugins' status/dashboard endpoints (mnemon_status, mnemon_memory_bodies).

Root cause

dsh-code-runtime-worker-thread/lib/worker.cjs snapshots call arguments before posting the call to the host:

try {
    detached = snapshotCodeJsonValue(args);
} catch {
    detached = void 0;
}
if (detached === void 0) return Promise.reject(bindingFailure(errorClass, name, "binding arguments must be lossless JSON"));

For a zero-argument call, args === undefined; the lossless-JSON snapshot of undefined is undefined, so the worker rejects before the message ever reaches the host. The binding function itself never runs.

Expected

Calling a zero-parameter binding — with no arguments — should invoke the binding with an empty parameter object, mirroring what the same tool receives on the direct (non-PTC) call path.

Suggested fix (applied locally, resolves the failure)

Treat only the absent arguments case as an empty parameter object; genuinely non-JSON arguments keep failing:

if (detached === void 0) {
    if (args === void 0) detached = {};
    else return Promise.reject(bindingFailure(errorClass, name, "binding arguments must be lossless JSON"));
}

Impact

Every zero-parameter tool binding is unusable in PTC mode. Plugin management/status endpoints are typically zero-argument (the "dashboard" surface), so plugins lose that entire surface in PTC mode while read/write paths keep working — which makes the breakage easy to misdiagnose as data corruption.

Happy to send the exact patch as a PR if helpful.

Happy to send the exact one-line patch as a PR if helpful.

[Mide69]

Confirmed against source, precisely. Found the actual TS source behind the lib/worker.cjs bundle you cited, in case it helps whoever picks this up: packages/code-runtime/code-runtime-worker-thread/src/bootstrap.ts, not worker.ts (the compiled filename doesn't map 1:1 to the source filename here).

Lines 328-336 are exactly the pattern you describe:

let detached: ReturnType
try {
detached = snapshotCodeJsonValue(args)
} catch {
detached = undefined
}
if (detached === undefined) {
return Promise.reject(bindingFailure(errorClass, name, 'binding arguments must be lossless JSON'))
}

And snapshotCodeJsonValue's own doc comment in worker-json.ts says exactly what you'd expect: "@returns a detached lossless-JSON snapshot, or undefined when invalid." For a zero-argument call args really is undefined, so the function's own contract makes "no arguments" and "invalid arguments" produce the identical undefined result, there's no way for the caller to tell them apart after the fact. That's the whole bug in one sentence.

Your fix is the minimal correct one, since it intercepts args === undefined before it ever reaches the ambiguous snapshot call, so genuinely invalid (non-JSON, circular, etc.) arguments still fail exactly as before. Nothing about the rest of the binding-call path needs to change.

Given you've already verified this locally and offered to send the exact patch, this looks ready to hand to a maintainer as-is.