Workflow tool: object args arrive stringified in the script; related evidence of within-session subagent co-deaths on connection close

Environment

• Claude Code 2.1.216 / 2.1.217 (both affected), Windows 11 Pro 10.0.26200, native installer
• Model: Claude Fable 5 / Opus 4.8 sessions

Bug 1 — Workflow args objects arrive as a JSON string

The Workflow tool's docs state args is "the value passed as Workflow's args input, verbatim" and warn users to pass "actual JSON values, NOT a JSON-encoded string." Passing a genuine JSON object still delivers a string to the script.

Controlled repro (zero agents):

Tool call input:

{ "script": "export const meta = { name: 'args-typeof-probe', description: 'probe', phases: [] }\nreturn { typeof_args: typeof args, value: args }", "args": {"researchDir": "C:/Dev/tmp/probe", "date": "2026-07-21", "n": 3} }

Result:

{"typeof_args":"string","value":"{\"researchDir\": \"C:/Dev/tmp/probe\", \"date\": \"2026-07-21\", \"n\": 3}"}

Expected: typeof_args === "object". The resume hint in the tool result also echoes args as a string, so the stringification appears to happen at the tool-call storage boundary, not in the script sandbox.

Impact: args.x evaluates undefined silently; scripts interpolate the literal text "undefined" into worker prompts (we had research workers write output to paths containing undefined and into wrong directories). Workaround we now enforce: const A = typeof args === 'string' ? JSON.parse(args) : args at every script top.

Bug 2 (evidence report) — subagent co-deaths are strictly within-session

Related to #60133 (transport). We keep an incident corpus (300+ events since May). On "Connection closed mid-response" errors:

• 19 co-death groups: ≥2 subagents of ONE parent session terminating within ≤2s — typically 7–13 ms apart — each final transcript event an assistant message with model: "<synthetic>" and zero further writes. Example: 2026-07-22T03:24:12.704Z and .714Z, two research agents of workflow wf_c9cac418-ec4, 27 of 29 siblings unaffected.
• Zero cross-session groups — with up to 6 concurrent sessions on the same machine/account, simultaneous kills never span sessions.

That pattern suggests the failure domain is a per-process shared connection/stream pool (one HTTP/2 connection multiplexing a session's concurrent streams dying → all its in-flight streams die together), rather than server-side or network-wide. Sharing in case it helps narrow #60133: a per-stream connection or a retry-once-on-stream-teardown for in-flight subagent requests would cut the blast radius of one closed connection from N workers to 1.

Happy to provide sanitized transcript excerpts or the incident corpus schema.