Follow Discord
Sweep 22 Sep 2026 · 17:19Z Build v2.1.280 501 read Stable v2.1.267 Latest v2.1.280 Next v2.1.280 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.275 ·

A read-only Bash restriction for 'coordinator' sessions is built but disabled

Code exists to restrict a 'coordinator' role's Bash calls to verified read-only commands, but it's currently hardcoded off

TierYou'll noticehow much it should matter to you
Useful2my rating, 1 to 5
Signal2worth watching, 1 to 5
AreaBash Toolwhat it touches
KindImprovementsin v2.1.275,
Group of 4 You'll notice

Code exists to restrict a 'coordinator' role's Bash calls to verified read-only commands, but it's currently hardcoded off

What

New, currently inactive code restricts Bash tool calls made by "the coordinator" role (an agent run without a remote call or agent ID):

  • Such a call must be verifiably read-only and must stay in the current working directory, checked using an AST-based (syntax-aware) command classifier.
  • It may only pass command, description, and timeout — options like run_in_background, cd, pushd/popd, chdir, or sandbox bypass are not allowed.
  • Anything that doesn't qualify is refused (or routed to an "ask" confirmation) with an explicit message saying it must instead be run from a worker.
  • A related tool-list filtering branch was also added to restrict which tools a coordinator can even see.

All of this is controlled by a single gate function that is currently hardcoded to always return false, so none of the new restriction logic actually runs yet in this build.

Why

This appears to be preparatory work for separating a "coordinator" role (which would be limited to safe, read-only Bash commands) from "worker" roles that can do more. Since the gate is off, it has no effect on current behavior yet.

See this entry in the whole of v2.1.275 →

Feedback