Filed unassigned by the domain:devx os-dev seat while landing #9575 / PR #9594. Observation about an instruction surface, not a code defect. Recording, not claiming. Dedup-searched over 221 open issues (workspace-concurrency): no existing card.
The observation
.claude/agents/os-dev.md:99 carries this as a toolchain trap:
--workspace-concurrency=2 放在 --filter之前;放在 filter 之后会被转发给底层脚本(且该 flag 不叫 --concurrency)。
The positional advice is right for the commands that accept the flag. It is not right for pnpm install, which is the first command every dispatch tells a dev to run in a fresh worktree — there the flag is rejected outright, position notwithstanding. Measured on pnpm 10.31.0, in a worktree of this repo:
$ pnpm install --workspace-concurrency=2 --ignore-scripts --filter @objectstack/spec-monorepo
ERROR Unknown option: 'workspace-concurrency'
Did you mean 'network-concurrency'? Use "--config.unknown=value" to force an unknown option.
pnpm recursive --help lists --workspace-concurrency as its own option; pnpm install --help and pnpm run --help only mention it in prose about recursive runs.
Why it is worth a line
The failure is loud, so nobody ships a wrong artifact over it — the cost is one wasted round trip at the exact moment an agent is following the worktree-first ritual and has no output yet to reason from. Both halves of the trap can hold at once: keep the positional rule for pnpm -r / pnpm run, and say that pnpm install does not take it.
Constraint on whoever picks this up
.claude/** is a governed surface — human-merge-only, never armed, never queued. This card is a request for a maintainer edit, not a task an agent can land on its own.
Ref: #9575 · PR #9594
Generated by Claude Code
Generated by Claude Code
Filed unassigned by the
domain:devxos-dev seat while landing #9575 / PR #9594. Observation about an instruction surface, not a code defect. Recording, not claiming. Dedup-searched over 221 open issues (workspace-concurrency): no existing card.The observation
.claude/agents/os-dev.md:99carries this as a toolchain trap:The positional advice is right for the commands that accept the flag. It is not right for
pnpm install, which is the first command every dispatch tells a dev to run in a fresh worktree — there the flag is rejected outright, position notwithstanding. Measured on pnpm 10.31.0, in a worktree of this repo:pnpm recursive --helplists--workspace-concurrencyas its own option;pnpm install --helpandpnpm run --helponly mention it in prose about recursive runs.Why it is worth a line
The failure is loud, so nobody ships a wrong artifact over it — the cost is one wasted round trip at the exact moment an agent is following the worktree-first ritual and has no output yet to reason from. Both halves of the trap can hold at once: keep the positional rule for
pnpm -r/pnpm run, and say thatpnpm installdoes not take it.Constraint on whoever picks this up
.claude/**is a governed surface — human-merge-only, never armed, never queued. This card is a request for a maintainer edit, not a task an agent can land on its own.Ref: #9575 · PR #9594
Generated by Claude Code
Generated by Claude Code