claude-code - 💡(How to fix) Fix Agent Teams: allow per-teammate cwd and additional working directories (subsets of the lead's access) at spawn time

AI :handshake: Greg — Claude collab with Greg:

Summary

In the Agent Teams feature, when the Lead / Orchestrator agent spawns teammates, allow specifying per teammate:

• a working_directory (cwd) for that teammate, and
• optionally a set of additional working directories the teammate is allowed to access (a subset of the directories the spawning Lead itself has access to).

The teammate would then start as if it were a fresh Claude Code session rooted in that cwd — picking up that directory's CLAUDE.md, .mcp.json, skills, etc. — and would be scoped to the subset of additional directories the Lead chose to grant.

Motivation

This lets the Lead build Agent Teams where each teammate operates over a subset of the directories the Lead has access to, instead of every teammate inheriting the Lead's full cwd and full directory set. That maps naturally onto how real teams work: each member is scoped to their part of the project and sees the rest only as needed.

Concrete examples this enables:

• Multi-repo coordination: a Lead with access to repo-a/, repo-b/, repo-c/ spawns teammate A rooted in repo-a/, teammate B rooted in repo-b/, etc., each picking up its own repo's CLAUDE.md / .mcp.json / skills.
• Worktrees: a teammate rooted in a specific git worktree without needing cd prefixes or absolute paths in every bash call.
• Specialist roles: a docs / meta agent rooted in a docs directory, with read access to code directories but no write access outside its own root.
• Plugin-shipped specialists: an agent rooted in its own source tree rather than the caller's tree.
• Read-only teammates via read-only (bind) mounts: spawn a teammate whose additional directories are read-only mounts of other repos, so the OS itself guarantees the teammate can only read that content (e.g., to review code and file issues) and physically cannot modify it. See details below.

<details> <summary>Why read-only mounts complement Claude Hooks (and aren't replaced by them)</summary>

Claude Hooks can help shape teammate behavior — especially if agent_type (or an equivalent field) clearly indicates that a tool call originates from a teammate rather than the Orchestrator Lead, so policy can branch on role. That's genuinely useful.

However, hooks are still per-tool-call checks. A single tool call (e.g. Bash) can invoke a script or program that internally operates on many paths across multiple directories. Validating every effective path a sub-process will touch from a hook is fragile in the general case.

Read-only bind mounts move the guarantee down to the operating-system layer: regardless of what script a tool call invokes, writes to a read-only mount fail at the kernel boundary. Combined with per-teammate additional_directories (with a read-only flag), this lets the Lead spawn teammates whose "see other repos, don't modify them, communicate findings via issues / messages / the team's shared task list" contract is enforced by the OS, not by prompt or hook logic.

The two layers compose nicely: hooks for fine-grained, role-aware policy on tool calls; read-only mounts for coarse, unforgeable filesystem boundaries underneath.

</details>

Proposed shape (sketch, not a spec)

At spawn time, per teammate:

• working_directory: path used as the teammate's cwd; CLAUDE.md, .mcp.json, and skills load from there like a fresh session.
• additional_directories: optional list of extra paths the teammate may access, each a subset of what the Lead itself has access to. Optionally with a read-only flag per entry, for cases where a teammate should see other repos / docs but not modify them — cleanly composable with OS-level read-only (bind) mounts.

The Lead cannot grant a teammate access to directories the Lead itself doesn't have — teammate scope is always a subset of Lead scope.

Current workaround

Running separate Claude Code sessions per directory (e.g., one per repo or per git worktree) and coordinating manually. This works but is out-of-session and loses the Agent Teams coordination affordances (shared task list, messaging, Lead orchestration).