claude-code - 💡(How to fix) Fix Expose a way to disable parallel tool execution (the API's disable_parallel_tool_use) in Claude Code

Summary

Claude Code has no setting to make tool calls run one at a time. The Messages API already supports tool_choice.disable_parallel_tool_use, but Claude Code doesn't surface it. Please expose it as a setting / env var / CLI flag.

Problem

When the model emits multiple tool calls in a single assistant message, Claude Code runs them concurrently. If one fails, the in-flight siblings are cancelled (Cancelled: parallel tool call X errored) and must be re-issued. For mutating tools (Bash, Edit, Write, …), a single fragile call's failure cascades across otherwise-fine sibling calls.

(v2.1.147 fixed this for read-only commands — "a failing read-only command no longer cancels sibling calls" — but mutating-tool failures still cancel siblings.)

Impact (measured)

Analyzing one real ~1,300-tool-call session: 21% of tool calls errored, and 78% of those errors (221 of 282) were collateral cancellations from parallel batches of mutating calls — each failed call wiping ~3.6 siblings, which then re-run. A disciplined, one-call-at-a-time session in the same project had a 3.5% error rate. Forced-sequential execution would cut the error/redo rate ~6x for this kind of workflow.

Why this can't be solved with a PreToolUse hook

I tried serializing mutating calls with a PreToolUse hook and hit hard limits — there is no reliable signal at decision time to tell whether a call is a sibling of another call in the same assistant message:

• The PreToolUse payload has only session_id and a per-call-unique tool_use_id — no batch/message id.
• transcript_path points at the session log, but the assistant message and its tool_use blocks are written after the PreToolUse hooks fire, so looking up our own tool_use_id returns "not found" at decision time.
• The Stop hook fires only at end-of-response, not between assistant messages, so a per-turn lock can't be reset per message.

A wall-clock timing heuristic works only partially — sibling spacing varies from ~100ms to >1500ms depending on the preceding call's duration, so no fixed window cleanly separates "sibling" from "next message".

Requested

Surface the API's existing capability in Claude Code, e.g. any of:

• settings.json: "disableParallelToolUse": true
• env var: CLAUDE_CODE_DISABLE_PARALLEL_TOOL_USE=1
• CLI flag: --disable-parallel-tool-use

Bonus: a scoped option (disable parallelism only for mutating tools, keep read-only fan-out parallel) would keep the speed benefit of parallel reads while removing the collateral-cancellation class entirely.