Who Controls the Fleet? What Agent Orchestrators Actually Do With Permission Prompts
Running Claude Code? See, control, and price every tool call it makes — allow/ask/deny policy, a per-session bill at API rates, and a full audit log, in one command:
curl -sf https://agenticcontrolplane.com/install.sh | bashFull Claude Code guide → · see your first governed call → · free up to 5 agents
The pitch for fleet orchestrators is real: fan one prompt across five agents in five worktrees, compare, merge the winner. Copilot CLI shipped /fleet in April. Orca manages ~30 harnesses side by side, with a phone app. claude-squad, Conductor, herdr, repomon each run a variant. The role the ecosystem is converging on — you manage a team of agents, not a session — depends on them.
Here’s the question nobody’s docs lead with: every agent in the fleet was built assuming a human answers its permission prompts. You just became five humans. What happens to the prompts?
We read the source and the docs of six orchestrators to find out. There are five distinct answers, and they’re worth knowing before you fan out.
Answer 1: the bypass flag, on by default (Orca)
Orca’s launch layer keeps a per-harness map of skip-approval flags — tui-agent-permissions.ts: --dangerously-skip-permissions for Claude Code, --dangerously-bypass-approvals-and-sandbox for Codex, --yolo for Gemini/Copilot/Cursor, --auto-approve true for Cline, --yes-always for Aider, and so on across ~30 agents.
That map is the default launch configuration — DEFAULT_TUI_AGENT_ARGS = YOLO_TUI_AGENT_ARGS — and a settings migration applies it to existing users who hadn’t customized launch args. To be fair to Orca: this is user-visible, not hidden — onboarding and Settings expose a “Yolo” vs “Manual” mode, and Manual passes each harness’s own prompts through. But yolo is the initialized default, there’s no policy layer or audit record in the repo, and the README doesn’t document the flag behavior. The product that makes it easiest to run ten agents also defaults all ten to their escape hatch.
Answer 2: a daemon presses Enter (claude-squad)
claude-squad’s -y / --autoyes mode (off by default) is more interesting than a flag: it doesn’t pass any permission option to Claude Code at all. A background daemon polls each tmux pane, string-matches known permission dialogs — the code looks for pane text like “No, and tell Claude what to do differently” — and presses Enter. It also auto-dismisses workspace trust prompts.
Screen-scraping the approval UI means no distinction between prompt types: a file edit and a git push --force get the same Enter. The project’s own issue tracker has a proposal to replace this with --permission-mode bypassPermissions — the fix for scrape-and-accept being, notably, a cleaner bypass.
Answer 3: another agent answers the prompt (repomon)
repomon’s phone-approval story is real — a token-gated WebSocket bridge over Tailscale lets you approve a prompt from your phone, and lane deletion gets a two-phase human confirmation. But its orchestrator agent, repomind, is documented as “answering their permission prompts, and merging finished work” — and its --autonomy flag defaults to autonomous, in which repomind “may create, merge, and delete lanes… without asking first,” bounded by an action cap.
An agent answering other agents’ permission prompts is delegation of the one thing the prompt existed to reserve for you. Claude Code’s own team docs (below) prohibit exactly this pattern internally.
Answer 4: pass it through, honestly (Conductor, herdr)
Conductor’s docs don’t dress it up: agents “run with the same permissions as your user account,” unsandboxed, and harness approval prompts surface in each workspace for you to answer — the suggested mitigation for risk is a separate machine or VM. herdr goes further in the honest direction: it’s an observation layer that marks an agent blocked when its screen shows a permission UI and explicitly won’t send input on the agent’s behalf.
Pass-through preserves the control and re-creates the bottleneck the orchestrator was bought to remove: one human, N panes, and the 13.6% catch rate humans manage at the prompt now spread across five of them.
Answer 5: documented inheritance (Claude Code agent teams)
The most thought-through answer in the set is Anthropic’s own, in the agent teams docs: teammates start with the lead’s permission settings; teammate prompts appear in the lead session so a human answers them centrally; a teammate “can’t approve a permission prompt or supply consent on your behalf,” a denied action can’t be relayed to another teammate to bypass the check, and auto mode’s classifier treats a relayed approval claim as untrusted input.
That’s real design: centralized asks plus explicit anti-laundering rules. It has two edges worth knowing. Inheritance cuts both ways — “if the lead runs with --dangerously-skip-permissions, all teammates do too” — and there’s no per-teammate mode at spawn time. And it’s the exception: GitHub’s /fleet documentation, for contrast, doesn’t say how Copilot CLI’s genuinely solid allow/deny tool rules apply to fleet-spawned subagents at all — the fleet pages pair instead with autopilot, which “auto-responds to requests that would otherwise require user intervention.”
The pattern under the answers
Line the five answers up and they’re all resolving the same tension: the fleet multiplies agents, but not you. Approval capacity stays at one. So the prompt gets bypassed (Orca), auto-accepted (claude-squad -y), delegated to an agent (repomind), centralized (Claude teams), or left as N panes you alt-tab between (Conductor).
What none of the six ship is the other half: a rule layer or a record. No orchestrator we read has per-tool policy of its own, and none keeps an audit record of what its agents ran — the herdr state log and Copilot’s /tasks view are liveness surfaces, not decision records. Which means fleet mode takes the four structural gaps of single-agent control — self-authored records, per-machine policy, one-flag escape hatches, rules that don’t travel — and multiplies them by the fleet size, then often adds the bypass flag on top.
Before you fan out
Three checks, none of which require abandoning your orchestrator:
- Run the empty-chair test on the orchestrator itself. What does it do with a prompt nobody answers? “Presses Enter” and “launched with the flag so there are no prompts” are answers you want to know about before the overnight run, not after.
- Check what survives the launch flags. If your fleet runs Claude Code with
--dangerously-skip-permissions, deny rules and hooks still fire — so put your limits there, in a layer the orchestrator’s launch map doesn’t touch. That’s pattern 5 and 7 territory: hooks and proxies hold regardless of how the agent was launched. - Get one record the fleet doesn’t write. Five agents, five worktrees, one overnight session — when one of them force-pushes, transcripts scattered across tmux panes are what you’ll have. An independent, off-machine record of every tool call across the fleet is the difference between reconstructing and knowing.
One human can’t answer five agents’ prompts — that part the orchestrators got right. The conclusion we’d argue for is different, though: the answer to too many asks isn’t no rules — it’s rules that answer for you, and a record of every answer. The fleet is one policy surface. It should have one policy.
Every claim above is from the linked source code, official docs, or issue trackers, as of 2026-08-26; orchestrators move fast, and we’ll correct this page when they do. How the same question plays out per-harness — rather than per-orchestrator — is the harness control patterns page.