cordis_define tool: plugin object parameter always fails oneOf validation (matched 0)

[crack-time]

Problem

When calling cordis_define from the Web GUI, the plugin parameter (a JSON object) always fails validation with:
Error: invalid arguments: "plugin" must match exactly one oneOf branch (matched 0)
The same issue occurs with cordis_inspect_query's input parameter (also an object type).

Reproduction

1. Start DSH: npx @deepseek-ai/dsh web
2. Open Web GUI at http://127.0.0.1:3080
3. Ask the agent to call cordis_define with:

{
  "plugin": {"kind": "new", "idPrefix": "hello"},
  "name": "Hello Tool",
  "purpose": "A simple test tool",
  "code": {"host": "return { apply: function(ctx) { console.log('hi') } }"}
}

4. The tool call returns the validation error above

Expected Behavior

The plugin parameter should accept a valid JSON object matching the first oneOf branch (kind: "new" + idPrefix).

Environment

• DSH: @deepseek-ai/dsh@0.1.0-rc.6 (npm)
• Node.js: v26.4.0
• OS: Windows
• Browser: Chrome (latest)

[AlexLimaTKZ]

I think this is probably not a oneOf semantics problem itself, but an object-validation / Web realm boundary issue in 0.1.0-rc.6.

There are two clues:

your plugin value matches the first branch correctly:
{
"kind": "new",
"idPrefix": "hello"
}
you mentioned that cordis_inspect_query.input, which is just a JSON/object parameter and does not depend on that particular oneOf, fails as well.

That makes the common denominator the nested object value, rather than the union itself.

The current validator has explicit support for plain JSON values across JavaScript realms, and oneOf validation counts how many branches successfully validate:

exactly 1 branch -> valid
0 branches -> "matched 0"
2+ branches -> invalid overlap

If the Web UI object is rejected before its properties are evaluated as a plain JSON record, both object branches fail and oneOf naturally reports:

must match exactly one oneOf branch (matched 0)

So the matched 0 message is likely the downstream symptom, not the root cause.

There is also a useful confirmation in current master: the Web E2E Cordis test explicitly asks the model to call cordis_define with:

plugin kind "new", idPrefix "snap"

and asserts that cordis_inspect_self → cordis_define → cordis_run → cordis_stop all complete successfully in the real Web composition.

In other words, this exact shape is expected to work in current source.

I would test:

npx @deepseek-ai/dsh@latest web

or, from current source:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Then retry the same call unchanged:

{
"plugin": {
"kind": "new",
"idPrefix": "hello"
},
"name": "Hello Tool",
"purpose": "A simple test tool",
"code": {
"host": "return { apply: function(ctx) { console.log('hi') } }"
}
}

If it works on current master but still fails on 0.1.0-rc.6, that would strongly indicate this is an rc.6 Web/object-boundary regression.

I would not remove the oneOf or change the plugin payload as a workaround, because the current cordis_define schema still intentionally uses the same discriminated oneOf:

kind: "new" + idPrefix
kind: "existing" + pluginId

So your original payload shape looks correct.

[sylvesterkaczmarek]

That payload looks valid against the current cordis_define schema.

plugin is a oneOf between {kind:"new", idPrefix:...} and {kind:"existing", pluginId:...}, so {"kind":"new","idPrefix":"hello"} should match the first branch. Since you're also seeing the same problem with the object-valued cordis_inspect_query.input, this looks more like an rc.6 argument-validation/object-normalization issue than a bad tool call.

I'd try the identical request against current main/latest first. If it still reproduces, logging the raw value immediately before schema validation should show whether its shape/prototype is being changed somewhere between the Web UI and the validator.

[gezi-wen]

I ran into the same thing on two machines (an Ubuntu server and my Windows laptop), and since the cordis_inspect_query failure was blocking all exact queries, I ended up digging through the shipped bundles to find where it actually breaks. Turns out three separate problems are stacked on top of each other:

First, the tool declares its input as type: "json", and the schema projection treats that as annotation-only. parameterSchemaSpecToJsonSchema in dsh-tools sends literally this to the model API:

"input": { "description": "Optional query input; ..." }

No type anywhere, so the model just has to guess what shape the field should be.

Second, faced with an untyped field, the API layer emits the nested object as a JSON string. I confirmed this by replicating the validator locally: JSON.parse output passes isPlainJsonRecord, a raw string doesn't.

Third, nothing downstream compensates. validateInput in dsh-cordis-host-runner checks args.input against each method's inputSchema (all of which require type: "object"), and nothing between transport and validation ever re-parses a stringified value.

One thing though — I don't think the cordis_define failure in #1122 is necessarily the same bug. Its plugin parameter is declared as oneOf over two object branches, and unlike type: "json", the projection keeps that fully intact, complete with type: "object" on the wire (checked by calling the exported function directly). So if both tools still end up receiving stringified objects, that points at something downstream of the projection — model/API behavior, or maybe whatever extra serialization hop the Web GUI adds. The inspect_query chain above, on the other hand, is completely explained by the missing type.

Scope seems contained, at least: I scanned the shipped dsh-tool-* packages and this input is the only input-side type: "json" parameter, which is why exact inspect queries break while catalog mode works fine. Also still present in 0.1.1-rc.1/rc.2, so this isn't a recent regression.

Something that works as a local stopgap — a defensive re-parse in cordis_inspect_query.execute:

 		async execute(args, exec) {
-			const data = await ctx.cordisInspect.query(args.platform, args.provider, args.method, args.input, requireAgent(exec), exec.signal);
+			let input = args.input;
+			if (typeof input === "string") {
+				try { input = JSON.parse(input); } catch { /* fall through */ }
+			}
+			const data = await ctx.cordisInspect.query(args.platform, args.provider, args.method, input, requireAgent(exec), exec.signal);
 			return {

Parse failures fall through to the normal validator error, so malformed strings still get reported properly.

Longer term, giving type: "json" parameters an explicit wire type in the projection seems like the cleaner fix — then the API never has to guess in the first place.

Caveat: both my machines route through the DeepSeek endpoint, so no idea whether other routes behave differently.

[gezi-wen]

Follow-up on the cordis_define half, since that's the part still open.

We couldn't easily instrument the Web GUI hop on our end, but we got at it from another angle: calling the tool directly through the harness execution layer (no GUI in between) and checking what the validator actually accepts. Two findings:

1. The oneOf validation itself behaves exactly as written. Both branches are additionalProperties: false, so a field from the other branch fails both at once. Concretely: {"kind":"existing","pluginId":"..."} passes, {"kind":"existing","pluginId":"...","idPrefix":"..."} fails with matched 0 — idPrefix belongs to the new branch. So a model that ever merges fields across branches (which untyped tool prompts invite) produces exactly the error in the original post, even though the schema is doing what it was told.

2. That still doesn't explain the original reproduction, where a clean {"kind":"new","idPrefix":"hello"} fails in the Web GUI — the same minimal payload passes when called directly through the execution layer. So something in the GUI path breaks the value before it reaches validation. My bet is the same hop that stringifies cordis_inspect_query.input: a string hitting oneOf<object, object> would fail both branches and report exactly matched 0. If true, one serialization hop is responsible for both tools' GUI symptoms, while the inspect_query failure I described earlier is how the no-GUI path fails on its own.

So the raw-value check suggested above — logging plugin right before validation in the GUI path — should settle it: if it prints a string, that's the whole story. I didn't want to patch shipped bundles just to peek at that hop, so leaving it to someone with a debuggable build. And if it does turn out to be stringification, the defensive re-parse I posted for inspect_query should work at the same boundary for plugin too.

[crack-time]

Confirmed the raw-value hypothesis. Added a console.log before validation in defineTool's execute wrapper in dsh-tools@0.1.1-rc.2:

[DEBUG cordis_define] args.plugin type: string value: "{"kind": "new", "idPrefix": "hello"}"

The plugin object arrives as a JSON string in the Web GUI path, exactly as you suspected — the same serialization hop that affects cordis_inspect_query.input. Both tools share one root cause: the Web GUI stringifies nested objects before they reach the validator.

The defensive JSON.parse re-parse at the validation boundary would fix both tools.

[sylvesterkaczmarek]

Thanks, that distinction is convincing. :) cordis_inspect_query.input is specifically explained by type: "json" losing its wire type during schema projection, while cordis_define.plugin retains its object-typed oneOf. We therefore should not assume they share a root cause without inspecting the raw plugin value at the Web/tool boundary.

The defensive parse is a useful stopgap for inspect_query; preserving an explicit wire schema for type: "json" is the cleaner fix.

[crack-time]

Update: working fix at defineTool level in dsh-tools

In both dsh-tools/lib/index.js and dsh-tools/lib/types/schema.js, replace the execute wrapper inside defineTool with:

async execute(args, exec) {
    function _coerceArgs(val) {
        if (typeof val === "string") {
            if (val.charCodeAt(0) === 123 || val.charCodeAt(0) === 91) {
                try { return JSON.parse(val); } catch { return val; }
            }
            return val;
        }
        if (Array.isArray(val)) return val.map(_coerceArgs);
        if (val !== null && typeof val === "object") {
            const out = {};
            for (const k of Object.keys(val)) out[k] = _coerceArgs(val[k]);
            return out;
        }
        return val;
    }
    const coerced = _coerceArgs(args);
    const violations = validate(coerced);
    if (violations.length > 0) throw new ToolArgsError(violations);
    return userExecute(coerced, exec);
}

The original execute wrapper was just the 3-line validate → throw → userExecute block. The _coerceArgs creates new objects (not mutating the frozen args) and recursively parses stringified JSON objects/arrays back to their proper types.

Tested on dsh-tools@0.1.1-rc.2, Windows + Chrome. cordis_define now succeeds; other tools unaffected.

[sylvesterkaczmarek]

That confirms the failure boundary. The oneOf validator is behaving correctly; the Web path is handing it the wrong runtime type.

I would avoid recursively JSON.parse-ing every string beginning with { or [ inside defineTool. A legitimate string argument may intentionally contain JSON text, and this would silently change its type before schema validation.

The safer fix is either to preserve nested JSON values in the Web/tool-call transport, or make any compatibility coercion schema-guided so it only applies where the declared schema expects an object, array, JSON value, or matching oneOf branch.

I would also add a Web-path regression covering both cordis_define.plugin and cordis_inspect_query.input.