Agent Teams: support per-teammate working directory, CLAUDE.md, and MCP configs

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23475
2. https://github.com/anthropics/claude-code/issues/12748
3. https://github.com/anthropics/claude-code/issues/17668

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Here's an additional scenario:

• repo A for docs and project management
• repo B, C, D for services code
• I'm working on a PRD document in repo A, I want Claude to run separate Claude session in repo B and C to do some analysis of how things currently work in the codebase to flag issues or explore feasibility

Separate CLAUDE.md files for different agent roles would be especially useful.

Also, when agents are spawned, their working directory is the same as the orchestrators. So to accomplish work in a worktree, they have to use absolute paths or prepend cd $MY_WORKTREE into every bash invocation, which wastes output tokens.

Would be good to be able to not only start team mates under a specified working directory but also supply the --worktree flag as well so that even if 2 teammates were sent to the same directory, they can start with their own isolated worktree.

The multi-repo agent team pattern is interesting — it highlights a broader problem: how do agents working across different contexts find and communicate with each other?

We've been building infrastructure for exactly this at Agenium. The core idea: each agent gets a permanent DNS address (agent://name.telegram) and an inbox, so agent teams can discover and message each other regardless of where they're running.

For the Claude Code team scenario:

• Each teammate could register as a separate agent with its own address and capabilities
• The team lead discovers teammates via the discovery API rather than hardcoded config
• Communication happens through the messaging layer — each agent has a persistent inbox

This is complementary to per-teammate working directory configs — the identity/communication layer would let agent teams span across not just repos but across different machines and even different LLM providers.

Demo agents with permanent addresses are live at chat.agenium.net if you want to see the messaging + discovery pattern in action.

The worktree point from @isupeene is spot on - we have agents wasting tokens on cd prefixes constantly. We run 9 agents across different models and had to give up on Agent Teams for cross-repo work entirely because of this limitation.

What worked for us was moving coordination outside of Claude Code itself. Each agent gets its own tmux session with the right cwd already set, tasks arrive via a webhook relay, and a shared append-only log handles the "who did what" problem. Less elegant than native Agent Teams support but it sidesteps the inherited-config issue completely. Repo is ide-agent-kit if anyone wants to compare notes.

Would love to see the -worktree flag idea from @ro0sterjam - that plus per-teammate CLAUDE.md would make native Agent Teams actually usable for multi-repo setups.

Following up here - we ended up building a standalone coordination layer that works regardless of how the IDE handles agent teams internally. Each agent gets a filesystem inbox, tasks get routed as JSON files, and results go into append-only logs.

The key insight was that trying to get the IDE to manage multi-agent orchestration is fighting against what it was designed for. Moving coordination to a separate layer means you can mix Claude, Gemini, GPT, or whatever - the agents just read tasks and write results.

Repo is at github.com/ThinkOffApp/ide-agent-kit if anyone wants to try it. We have been running 9 agents across 3 IDEs with it for a month.

it would be super helpful!

Appreciate the support. One key distinction from external coordination services: our workaround stays filesystem-native and repo-local (per-repo instructions/config + append-only receipts), so teams can run it self-hosted without adding another hosted dependency in the critical path. Still, this should be a first-class Claude Code capability — native per-teammate working directory/config would remove most of this glue.

Update: v0.3.1 now handles cross-machine agent coordination out of the box. Each agent works in its own directory on its own machine, and coordination goes through the message layer.

For the per-repo config problem specifically — we ended up with a single config file that maps rooms to agents, so each agent only picks up tasks relevant to its workspace. Not as clean as native per-teammate CLAUDE.md support would be, but it works reliably in production.

Bump on this feature request. It's a must have for any organization working with microservices.

Strongly support this. @ro0sterjam's original issue (#27578) and @hugobarauna's description here cover the core ask well — per-teammate working_directory with automatic CLAUDE.md/MCP/.mcp.json pickup. I want to add a pattern I use today that takes this further and might inform the design.

Beyond cwd: filesystem isolation via read-only bind mounts

Once teammates can have their own working_directory, the next question is: should they also have read-only access to other repos without being able to accidentally mutate them?

This mirrors how real teams work — developers are scoped to their repos and interact with other teams' code through interfaces (design docs, API contracts, code review), not by directly editing each other's files.

On Linux, I enforce this today with read-only bind mounts:

# Setup: create read-only mirrors of all project repos
REPOS=(repo-a repo-b repo-c)
for repo in "${REPOS[@]}"; do
  mkdir -p /workspace/all-repos/$repo
  sudo mount --bind /workspace/$repo /workspace/all-repos/$repo
  sudo mount -o remount,bind,ro /workspace/all-repos/$repo
done

Resulting layout:

/workspace/
├── repo-a/          # writable (repo A agents work here)
├── repo-b/          # writable (repo B agents work here)
├── repo-c/          # writable (repo C agents work here)
├── meta/            # writable (design docs, specs, decisions)
└── all-repos/       # read-only bind mounts
    ├── repo-a/      # read-only (live mirror of /workspace/repo-a)
    ├── repo-b/      # read-only
    └── repo-c/      # read-only

Bind mounts reflect changes in real time (same filesystem, just mounted read-only), so agents see each other's latest work immediately. The OS enforces the boundary — no prompt engineering needed:

# Verify: writes to read-only mirror fail at OS level
touch /workspace/all-repos/repo-a/test.txt
# touch: cannot touch '...': Read-only file system

For persistence across reboots, add to /etc/fstab:

/workspace/repo-a  /workspace/all-repos/repo-a  none  bind,ro  0  0
/workspace/repo-b  /workspace/all-repos/repo-b  none  bind,ro  0  0
/workspace/repo-c  /workspace/all-repos/repo-c  none  bind,ro  0  0

Team structure: multiple agents per repo + meta agents

My teams are larger than one-agent-per-repo. A typical setup:

Repo A agents:  A1, A2, A3, A4    → cwd: /workspace/repo-a  (writable)
Repo B agents:  B1, B2, B3, B4    → cwd: /workspace/repo-b  (writable)
Repo C agents:  C1, C2            → cwd: /workspace/repo-c  (writable)
Meta agents:    M1, M2, M3        → cwd: /workspace/meta     (writable)
Coordinator:    Lead               → pure communication layer

All agents also get --add-dir /workspace/all-repos for read-only cross-repo visibility.

• Repo agents (A1–A4, B1–B4, etc.) implement within their repo. They inspect other repos' types, interfaces, and contracts via the read-only mounts.
• Meta agents (M1–M3) don't touch code at all. They focus on thinking, design, architecture, and project management — working in a meta-repo with design docs, specs, and decision logs. They communicate with repo agents via files and version control, similar to how human teams use RFCs.
• The lead agent acts as a pure communication/transport layer — no thinking, no implementation, just orchestration. This preserves its full context window for coordination and avoids context exhaustion from doing actual work.

This gives each agent focused clarity on where to pay attention. The filesystem boundaries enforce it at the OS level.

Design suggestion

Beyond working_directory per teammate, it would be powerful to also support:

• Per-teammate read-only additional directories (like --add-dir but scoped per agent, optionally read-only)

The bind-mount scaffolding works today but is manual setup outside of Claude Code. Native support for working_directory + scoped --add-dir per teammate would make these patterns first-class.

This would greatly improve our workflows. We have a multi-repo setup where the team lead/orchestrator would delegate work into another repository, and per-teammate working directory support would let each agent operate in the correct codebase instead of the parent repo.

In addition to the current body, we’d also need teammates to automatically pick up the target repository’s local Claude configuration - especially repo-specific rules, skills, and hooks - so each delegated agent behaves like a native agent in that repo. Without that, cross-repo delegation is still fragile because the worker can have the right cwd but the wrong operational context.

/tmp/issue-23669-comment.md

Been hitting this exact wall, so I built a thing: crew-code

Claude Code Agent Teams already have messaging and coordination built in. The problem is you can't control how the team lead spawns agents. They all inherit the same working directory, same CLAUDE.md, same MCP config.

The tool fixes that by letting you predefine agents with their own working directories. Each agent is a native Claude Code session rooted in its own repo, so it picks up that repo's CLAUDE.md, .mcp.json, project context - exactly like you'd get if you opened a fresh claude session there by hand.

crew agent create my-feature --name frontend --cwd ~/repos/webapp
crew agent create my-feature --name backend --cwd ~/repos/api

You can also define entire teams as blueprints (YAML) and spin them up in one go - no manual setup each time.

Still early, but it's been solving the multi-repo coordination problem for me. Let me know what you think! 😊

to maximize this kind of freedom, we have built an orchestration framework to even allow you to orchestrate claude agents in different project/docker/user/hosts, communicating via http, see https://github.com/igamenovoer/houmao

Adding a use case that's structurally different from the multi-repo-monolith ones in this thread:

I'm building a design-system specialist agent that should be shipped as a Claude Code plugin and invoked from our iOS and Android product repos (which are entirely separate codebases with their own CLAUDE.md, skills, and MCP configs). The specialist's "brain" lives in a third repo — docs, skills, memory, Figma MCP wiring. Engineering sessions in the product repos call it to ask "what component should I use for X?" or "adapt this iOS screen to Android," and the specialist needs to read/write its own repo (commit docs updates, memory entries) without the caller's CLAUDE.md or skill set bleeding in.

This is the plugin-distributed shared specialist pattern — distinct from the multi-repo coordination cases already raised here. It's important because plugins are becoming the standard distribution channel for shared capabilities (wshobson/agents, the Figma plugin, etc.), but plugin-shipped subagents inherit the calling session's cwd, so a plugin can't ship an agent that operates against its own source tree.

The community workarounds in this thread (crew-code, ide-agent-kit, houmao, bind mounts) are all out-of-process orchestration. That was acceptable before, but with the May-13 policy making claude -p / Agent SDK / spawned terminal sessions count as extra-usage, subscription users are now boxed in: in-session subagents are the only subscription-billed path, and they can't change cwd.

Concrete ask aligned with the existing proposal: add working_directory: to the agent definition frontmatter (plugin agents included), with the agent loading CLAUDE.md, skills, and .mcp.json from that directory on spawn — exactly like the OP's "fresh Claude Code session" behavior. Even better: per-agent --add-dir so the specialist can read/write its source repo while operating from the caller's tree.

Happy to share more detail on the design-agent setup if it would be useful prior-art for the design discussion.

AI :handshake: Greg — Claude collab with Greg:

@marciogranzotto — good addition; the plugin-distributed shared-specialist case is genuinely distinct from the multi-repo-monolith setups here, and thanks for the accurate recall of the bind-mount pattern.

Taking the [announced change](https://www.xda-developers.com/anthropics-claude-subscriptions-no-longer-include-agent-sdk-and-claude-p-usage/) as given (subscription usage no longer covering claude -p / Agent SDK), the conclusion shifts in a useful direction rather than a dead end:

• **The out-of-process orchestration workarounds (crew-code, ide-agent-kit, houmao) lose their main motivation** — they existed largely to stay on a subscription via spawned claude -p sessions.
• [Agent Teams](https://code.claude.com/docs/en/agent-teams) is the in-session, subscription-billed path that recovers most of what that loses — teammates are "separate Claude Code instances," each "a full, independent Claude Code session," but spawned and coordinated by the lead in-session, not via claude -p / SDK / manual terminals.
• **Read-only mounts are not retired by any of this** — they're a kernel-level isolation primitive, orthogonal to billing or process model, and they compose into Agent Teams.

The one concrete ask: let the lead set, per teammate at spawn, (1) working_directory — with CLAUDE.md / .mcp.json / skills loaded from there, exactly like a fresh session — and (2) additional directories with an optional read-only flag. That makes the writable-own-repo + shared-read-only-all-repos/ layout a first-class spawn option instead of manual OS scaffolding.

<details>
<summary><b>Why the read-only mount still matters even with hooks (the load-bearing point)</b></summary>

A PreToolUse hook fires on tool calls, not syscalls. When the agent runs Bash ./tool.sh, the hook sees the command string and can allow or deny that invocation — but once the process runs, there is no per-syscall ("strace-style") hook supervising what it writes. Any script or binary the agent shells out to is therefore a structural blind spot for hooks.

A read-only bind mount closes exactly that blind spot: the kernel enforces it on every write, by any process, with no per-operation interception and without trusting the tool to behave. The only thing trusted is that the tool was pointed at the read-only view.

This is why the mount and the hook are different kinds of thing, and why one doesn't replace the other:

<details>
<summary>Hook = best-effort routing · mount = enforced boundary</summary>

• The hook (branching on agent_id, or PID, or just cwd) is fine for routing — deciding which writable tree a given agent should touch — and as a defense-in-depth guardrail on Claude's own tool calls. It does not have to be bulletproof, because it is not the boundary.
• The mount is the boundary: OS-enforced, covers spawned subprocesses the hook can't see, no trust in tool behavior required.
• Belt-and-suspenders: the hook handles dynamic per-agent logic; the kernel handles the hard floor. See the [Hooks reference](https://code.claude.com/docs/en/hooks) and the "block protected files" pattern in the [Hooks guide](https://code.claude.com/docs/en/hooks-guide).
• Scope caveat: the mount protects the mounted view. A tool that independently resolves the underlying writable path is out of scope — point tools at the read-only view, don't rely on them avoiding the original.

</details>
</details>

<details>
<summary><b>Why Agent Teams is the right home for this, with the gap quoted from the docs</b></summary>

From the [Agent Teams docs](https://code.claude.com/docs/en/agent-teams):

• On spawn a teammate "loads the same project context as a regular session: CLAUDE.md, MCP servers, and skills" — there is no per-teammate working_directory and no scoped per-teammate --add-dir.
• The Limitations section already concedes the adjacent case: "you can't set per-teammate modes at spawn time." The pattern of missing spawn-time per-teammate scoping is already acknowledged; this ask extends it to the directory dimension.
• Net: Agent Teams already provides the separate-process substrate the bind mount needs. The only missing piece is that the lead can't set the per-teammate directories at spawn. So this isn't superseded by Agent Teams — it's the missing scoping knob on Agent Teams.

<details>
<summary>Transport disambiguation (minor, for later readers)</summary>

Channels, Remote Control, and the Agent Teams mailbox are three distinct mechanisms, not one shared bus: [Channels](https://code.claude.com/docs/en/channels) pushes events from non-Claude sources (Telegram/Discord/iMessage/webhooks) into a running session; [Remote Control](https://code.claude.com/docs/en/remote-control) drives a local session from claude.ai/mobile; the mailbox is the built-in inter-teammate bus. For a manual multi-session setup, the coordination substrate is shared filesystem / VCS / issues — not Channels.

</details>
</details>

A narrower, separate question falls out of this and is worth its own issue rather than overloading this one: teammates are full sessions, not subagents, so the documented agent_id / agent_type hook fields — scoped to the subagent path — may not even be populated for a teammate's tool calls, which would mean per-teammate policy isn't expressible via hooks at all and must be a spawn-time parameter. Happy to file that as a standalone issue (a documented team_name/teammate field on tool events, paralleling the existing team-aware TeammateIdle) and link it here.

Meanwhile the supported manual fallback works today — multiple sessions each with its own cwd ([Git worktrees](https://code.claude.com/docs/en/worktrees) being the docs-blessed form), coordinating through whatever shared substrate fits. It's heavier and out-of-session, which is itself the argument for folding per-teammate working_directory + read-only --add-dir into Agent Teams spawn.

---

Filed as a focused, standalone feature request on the Agent Teams spawn surface: #59838 — proposing per-teammate working_directory + additional_directories (as subsets of the Lead's access, with optional read-only flag, composable with OS-level read-only bind mounts). Drafted in collab with Claude ( AI :handshake: Greg )

@gwpl great synthesis — the per-teammate working_directory + scoped read-only --add-dir ask captures exactly what's missing from the Agent Teams spawn surface.

Adding another data point from a structurally different direction we've been running with in production for the past few weeks: federated peer sessions rather than lead-and-teammates.

Why a different shape

The design-system specialist scenario I sketched above doesn't actually want a lead — neither the iOS session nor the design-agent session is naturally subordinate. Each is a sovereign Claude Code session, rooted in its own repo, with its own CLAUDE.md / skills / .mcp.json / memory. The collaboration is conversational, not hierarchical — "what component should I use here?", "here's the new token, please update your screens."

Agent Teams (even with the proposed working_directory fix) is the wrong shape for this: it presumes a lead spawning workers. What we actually needed was two existing sessions able to talk to each other without either giving up its native context.

Implementing it as a plugin (≈600 lines of bash)

The whole thing is a small Claude Code plugin — a handful of slash commands plus a shared library. No daemon, no orchestrator, no extra long-running processes. The full primitive list:

State layout (under ~/.claude/agent-bus/ or $XDG_STATE_HOME/agent-bus/):

registry/<name>.json         — { name, pid, cwd, registered_at }
mailboxes/<name>/
  inbox/                     — undelivered <ulid>.md files
  cur/                       — delivered (audit only)
  corrupted/                 — parse failures
threads/<thread-id>.md       — append-only conversation logs
.locks/                      — short-lived mkdir locks

Slash commands (each is a markdown file that shells out to a bash script):

• /bus-register <name> — writes a registry entry with the session's PID and cwd, then arms a persistent in-session Monitor task on the inbox directory (backed by fswatch -0). The Monitor's stdout becomes a notification the session sees mid-turn.
• /bus-deregister — removes the registry entry and stops the Monitor.
• /bus-listen — re-arms the Monitor (recovery after /clear or a session restart).
• /bus-thread <recipient> "<subject>" "<body>" — generates a ULID, writes the first message to threads/<id>.md (append-only), drops a tiny pointer file into the recipient's inbox/.
• /bus-reply <thread_id> "<body>" — appends to the thread file, drops a pointer in the recipient's inbox.
• /bus-list — shows online peers and active threads.
• /bus-read <thread_id> — prints the thread file.

Liveness is kill -0 <pid> against the registry — stale entries (sessions that crashed without deregistering) are detected on every list and ignored. No heartbeat loop needed.

The fswatch → Monitor wiring is the load-bearing trick. Claude Code's Monitor tool surfaces each stdout line from a background process as a notification to the session. So:

fswatch -0 ~/.claude/agent-bus/mailboxes/<name>/inbox/

piped into a Monitor task means the receiving session gets a notification the moment a new inbox file appears — no polling, no extra processes, and the notification arrives mid-turn so the session can react immediately. The notification text just says "new message in inbox for <name>"; the session reads the file itself.

PID identification has one gotcha worth flagging: walk parent PIDs from the slash command's shell up to the first claude process (use ps -o comm= strict-equal claude, not substring match on argv — substring match catches the Bash-tool's zsh snapshot path and latches onto the wrong PID). Store that as the session's identity.

Auto-register per repo: one line in CLAUDE.md ("On turn 1, if the plugin is installed, run /bus-register <name>") makes specialist repos permanently reachable by name.

Where it sits relative to the rest of the thread

| Approach | Coordination model | Where context lives |
|---|---|---|
| Agent Teams + per-teammate working_directory (gwpl's ask) | Lead spawns workers | Loaded at spawn from each worker's cwd |
| crew-code / ide-agent-kit / houmao | Out-of-process orchestrator | Per-agent, but coordination is external |
| Read-only bind mounts | OS-enforced isolation | Orthogonal to the above |
| Peer message bus (above) | Peer sessions, no lead | Native to each session, never inherited |

These are complementary, not competing. Agent Teams with proper per-teammate scoping is the right primitive for hierarchical multi-repo work; peer messaging is the right primitive for "two specialists who need to talk." We use peer messaging because the specialist's repo is its own thing with its own lifecycle, not a worker spawned for a task.

What this implies for the native ask

Even with per-teammate working_directory shipped, there's still a missing primitive: letting two existing sessions discover and message each other. Agent Teams' mailbox is in-team-only. A native equivalent — sessions can opt into a machine-local namespace and exchange threaded messages — would let plugin-distributed specialists work without each consumer having to wrap them in a team.

Picking up @marciogranzotto's federated-specialist case and the running thread on per-teammate working_directory / scoped --add-dir:

The reason this ask keeps getting expanded by adjacent shapes — multi-repo monolith (the OP), plugin-distributed shared specialist (@marciogranzotto), cross-machine federated agents (@ThinkOffApp's crew-code work) — is that **per-teammate working directory is just one slice of a more general invariant: a teammate is currently spawned as a child of its orchestrator's environment rather than as an independently-configured worker the orchestrator hands work to.** Everything that breaks when you cross a repo, a worktree, a host, or a permission boundary is downstream of that one design choice.

Three things I'd add to the eventual spec, from running tier-routed multi-process orchestration in an adjacent coordinator-shaped context:

**1. working_directory alone is necessary-but-not-sufficient — the load path for context is what users actually want isolated.** If the teammate boots in repo B but the team-lead's CLAUDE.md and .mcp.json are still in scope (via inheritance), the teammate will quietly mix instructions. The fix has to be: spawning into a directory resets the configuration root to that directory, the same way a fresh claude session does. Anything less reproduces today's "ambient context leaks into the worker" failure mode, just at a deeper level.

2. Same shape applies to MCP server scope. .mcp.json in repo A wires up an internal service A; repo B's .mcp.json wires up service B. If both load into the same teammate process (because spawn inherits), tool names collide and the teammate now has access to MCP surfaces the user never sanctioned for that workstream. Per-teammate MCP scope is a permission concern, not just an ergonomic one.

3. The auto-mode / pipeline-continuity bug (#54879) compounds this. Even after you give a teammate the right config, today's orchestrator yields back to the user after each Agent tool return ~47% of the time per the repro there. So the multi-repo team-lead pattern this issue is asking for is structurally double-blocked: spawn surface lacks per-teammate config (this issue) AND the dispatch loop won't run to completion without user nudges (#54879). Whichever is fixed first, the other still defeats the workflow.

The working_directory + scoped --add-dir shape @gwpl synthesized covers the day-one ergonomic ask. The bigger fix — and the one that makes plugin-distributed-specialist and cross-host federation actually work without each setup reinventing a coordination layer outside the Agent Teams surface — is: define a teammate spawn as a configuration-isolated child process whose only inheritance from the orchestrator is the assignment payload and the shared messaging channel. Working directory, CLAUDE.md, MCP config, permissions, model/effort overrides — all of those should be slot-able per teammate or default to the teammate's spawn-root.

That framing is also forward-compatible with the cross-machine pattern @ThinkOffApp described — filesystem-native receipts and per-agent directory roots are a clean superset of "per-teammate working_directory" once the inheritance assumption is gone.

from what I read, what the community actually needs is a standardized official agent communication sdk, that allows developers to orchestrate completely isolated custom-started claude processes without inventing workarounds. The way to spawn processes is very diverse in development works, I don't think claude can cover them all, that part is better left for developers. If such sdk is available, we may see truely universal and reusable solutions come up and later be intergated into official product.

Concrete pointer for the tmux/split-pane path: teammate panes are created without a -c start-directory, so they inherit the lead's cwd.

Grepping the shipped bundle (v2.1.156), the teammate pane is created via tmux split-window with no -c flag:

split-window -t <target> -h -P -F #{pane_id}
split-window -t <target> -v|-h -P -F #{pane_id}   // "Failed to create teammate pane: ..."

then the teammate claude is launched by injecting keystrokes into that pane (send-keys -t <pane> <cmd> Enter). With no -c, the new pane inherits the lead pane's cwd, so the fresh claude boots there and loads the lead's CLAUDE.md/.mcp.json/skills instead of the target repo's.

The same bundle already uses tmux's start-directory elsewhere (a dev-watch path):

split-window -h -t <t> -c <dir>   ({ cwd: <dir> })

so the capability is present — it's just not wired to a per-teammate value.

Minimal fix (split-pane mode): thread the spawn-time working_directory requested here (and in #59838) into the teammate split-window as -c <working_directory>. Since each teammate is a fresh claude process started in that pane, starting it in the right directory is sufficient for it to pick up that dir's CLAUDE.md, .mcp.json, and skills — exactly the multi-repo case described in this issue.

Scope caveats (honest):

• This only addresses split-pane (tmux / iTerm2) mode. In-process teammates share the lead's single OS process (process.cwd()), so per-teammate cwd there isn't achievable without a child-process spawn path, or it should be documented as unsupported for per-teammate roots.
• Consistent with #62904: Agent(cwd: …) is currently accepted but a no-op (the value isn't consumed by either spawn path).

Happy to test a patch against a multi-repo setup if useful.

One field data point on gwpl's read-only cross-repo idea, since it matches how our agents already work. Each of our agents runs with its own isolated workspace, its own CLAUDE.md, its own auth, and its own MCP set, because in a multi-model fleet you cannot share a single inherited config (different agents literally need different credentials and tool surfaces). We enforce that today outside Claude Code, with each agent pinned to its own cwd so we never pay the cd-prefix token tax isupeene flagged.

The piece gwpl raises that we'd most want native is per-teammate scoped additional directories, ideally read-only. Right now "this agent may read repo B but must not write it" is something we can only enforce at the OS/process boundary, not declare per-teammate in the team config. Per-teammate working_directory plus per-teammate --add-dir (with a read-only option) would cover most of why we moved team orchestration out of the IDE. The isolation we want is not just "different folder," it's "different folder, different config, different auth, different read scope," and those four travel together.