isolation:"worktree" is a no-op for tmux teammates (CLI 2.1.191) — agents share orchestrator tree

Summary

When spawning a teammate via the Agent tool with isolation: "worktree", the teammate does not get its own git worktree. It runs in the orchestrator's working tree on the orchestrator's branch, and any file it writes lands in the orchestrator's tree. This happens on the tmux teammate backend (confirmed via the shutdown metadata "backendType":"tmux"), and on both foreground and run_in_background: true spawns.

The flag appears to be silently dropped: a real tmux pane is created, but no separate worktree is.

Environment

• Claude Code CLI: 2.1.191
• Backend: tmux teammates (backendType: "tmux", real pane allocated)
• macOS (Darwin 25.5.0)
• Large monorepo with ~300 existing git worktrees registered (agent-worktree pool)

Repro

1. From an orchestrator session running inside a git worktree on branch X, spawn a teammate:

Agent(subagent_type: "general-purpose", isolation: "worktree", name: "probe", prompt: "...")

1. Have the teammate run and report:

• pwd
• git rev-parse --show-toplevel
• git rev-parse --abbrev-ref HEAD
• git worktree list | wc -l
• echo marker > probe_marker.txt (write a file into its cwd)

1. From the orchestrator, before/after the spawn, run git worktree list | wc -l and git status.

Expected

• Teammate gets a fresh worktree (e.g. worktree-agent-<id>) on its own branch.
• git worktree list count increases by 1.
• The teammate's marker file is not visible in the orchestrator's git status.

Actual

• Teammate's pwd / toplevel / branch == the orchestrator's worktree + branch.
• git worktree list count is unchanged (no new worktree registered).
• The teammate's marker file appears as untracked in the orchestrator's git status — i.e. both agents share one tree.
• Identical result with run_in_background: true.

Impact

The whole point of isolation: "worktree" is to let multiple agents edit files in parallel without conflicting. With it a no-op, two concurrently-dispatched agents write the same working tree and stomp each other's HEAD / uncommitted changes. Teams currently cannot safely fan out file-mutating work.

Notably, a teammate asked to self-verify reports "isolation confirmed" — because it is sitting in a worktree (the orchestrator's), it cannot distinguish an inherited worktree from a freshly-spawned one. The failure is only visible from outside (worktree-count delta + the marker showing up in the orchestrator's own tree).

Notes / question

We believe this is a regression — isolation: "worktree" did create separate worktrees on an earlier CLI (we think it changed around the …178 line, but haven't bisected the exact version). Could you confirm whether per-teammate worktree isolation on the tmux backend is intended to still work, or whether this behaviour is now by design? If intended, what's the supported way to give each tmux teammate its own worktree?

Happy to provide the full transcript / a minimal repro repo.