Workflow tool: args object delivered to script as JSON string (schema's untyped `args` → model emits string; dup of #72248) — bug 2 in original report retracted

Minimal reproduction for Bug 1 (zero agents, deterministic):

export const meta = { name: 'args-type-probe', description: 'probe', phases: [] }
return {
  typeofArgs: typeof args,
  isArray: Array.isArray(args),
  keysIfObject: (typeof args === 'object' && args !== null) ? Object.keys(args) : null,
  first80: String(args).slice(0, 80),
}

Invoked with args: {"probe": [1, 2, 3], "nested": {"a": true}} (a JSON object, exactly as the tool docs instruct).

Result:

{"typeofArgs":"string","isArray":false,"keysIfObject":null,"first80":"{\"probe\": [1, 2, 3], \"nested\": {\"a\": true}}"}

So the script receives a JSON string where the docs promise the value "verbatim". This rules out the original 100+-line script as a factor. Note the args parameter in the Workflow tool schema has no type field (description only) — a schema-driven parameter parser that only JSON-parses explicitly typed object/array params would leave it as a raw string, which would explain the behavior.

(Bug 2 is timing-dependent and not reproducible on demand, but the original evidence is a same-source contradiction: the harness's own <task-notification> claimed status: completed / agents_done: 52 while the harness's own TaskOutput API simultaneously returned status: running and the run's journal.jsonl was still growing — verified across multiple timestamped checks.)

Still reproduces on v2.1.209 (native install, darwin-arm64).

Ran the same zero-variable probe — passed args: {"probe": true, "list": [1, 2, 3], "nested": {"a": 1}} as a JSON object per the tool schema, script received:

{"typeofArgs": "string", "isArray": false, "keysIfObject": null}

Bug 2 (premature completion notification) did not occur in this short run (3s, 3 agents — notification matched journal state), but the original occurrence was on a ~24-min 52-agent run, so this is not evidence it is fixed.

Update — Bug 1 root cause is likely NOT the workflow runtime; it is upstream, at tool-call emission, driven by the untyped args schema. This issue is a duplicate of #72248 (and of the auto-closed #63253, which contains a full root-cause analysis).

New evidence from this session (v2.1.209, claude-fable-5, darwin-arm64): I inspected the session transcript JSONL — the API-level record of the assistant's tool_use block. input.args was already a JSON-encoded string in the emitted tool call, before the Workflow runtime ever ran. This matches grimreaper0's transcript finding in #72248 and Slooz's corpus scan in #63253 (11/11 args payloads stringified across 10 sessions, while typed array/object params of other tools were real structure 100% of the time).

So the sharpened diagnosis: args is the only Workflow parameter with no type in its input schema, and with nothing to anchor to, the model serializes the payload. Suggested fixes from #63253 still stand: (1) declare a concrete type for args in the schema, or (2) JSON.parse string-valued args in the runtime before exposing the script global (accept both shapes).

Client-side workaround (works reliably): const A = typeof args === 'string' ? JSON.parse(args) : args at the top of every script.

Note: #63253 was auto-closed for inactivity (NOT_PLANNED), not fixed — the defect is still live on 2.1.209.

Correction — Bug 2 (premature 'completed' notification) is RETRACTED after full transcript forensics. It did not happen; it was a model-side misnarration of three real but separate events.

I replayed the raw session JSONL (every queue-operation enqueue/remove and delivered <task-notification> attachment is recorded there). Findings:

1. The only early notification (T+0s, at launch) belonged to the first, instantly-crashed run (args bug → TypeError: pipeline() expects an array) and its status was failed — not completed, and it contained no agent counts.
2. For the resumed 52-agent run, the transcript contains no notification at all until T+24min, and that one coincided to the second with the journal's last write and with TaskOutput flipping to completed. The completion notification was accurate and on time.
3. In between, TaskOutput consistently and correctly reported running (checked at T+5m, T+8m, T+18m).
4. The '0-byte output file' was the still-running task's output file, read before completion — expected behavior.

The assistant then wove (failed-run notification) + (empty output file of a running task) + (partial journal) into a 'premature completed notification' story after the fact. That failure mode is already catalogued as #77291 (model fabricates task-notification blocks) / #68922 (model asserts completion before notification) — it is a model-behavior issue, not workflow-runtime plumbing.

I also scanned every Workflow run on this machine (8 sessions, 25 Workflow calls, 13 run dirs, v2.1.165→2.1.209): zero cases of a completion notification preceding the journal's last write; all completed notifications matched final journal state to within ~1s. Meanwhile Bug 1 (args stringification) was 4/4 = 100% whenever args was passed.

So this issue should be treated as Bug 1 only. Sorry for the noise on Bug 2 — retitling accordingly.