[FEATURE] Agent view: opt-out of worktree isolation and reuse heavy dependency directories

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Agent view (research preview, v2.1.139+) is a great organizational paradigm for managing multiple Claude Code sessions, and I genuinely enjoy using it. However, the always-on worktree isolation creates two compounding friction points that, together, make daily use painful — especially for solo developers and frontend workflows.
Pain point 1: Worktree isolation is forced, with no opt-out
Every session dispatched through agent view (or via /bg / claude --bg) is automatically moved into an isolated git worktree under .claude/worktrees/ before it edits files. There is currently no setting to disable this behavior at the agent view level.
I understand the rationale: parallel sessions could conflict if they wrote to the same checkout. But this is a defensive default aimed at users who run many concurrent sessions and may lose track of them. For users who manage their session lifecycle carefully and intentionally want a session to land changes on the current branch, the isolation is pure overhead.
Notably, the underlying mechanism already exposes the concept of opt-in isolation:

"To make a subagent always run in its own worktree regardless of how it was started, set isolation: worktree in its frontmatter."
— agent view docs

The naming (isolation: worktree) strongly implies that other isolation modes (e.g. isolation: none) are conceptually anticipated. Agent view top-level sessions should be able to opt into the same flexibility.
Pain point 2: Heavy dependency directories don't carry over to new worktrees
Even if I accept "every modification spawns a new worktree," the workflow breaks down for any project with substantial local dependencies — most acutely for frontend work. node_modules is not tracked by git and therefore does not appear in the new worktree. To actually run the project (start the dev server, run tests, build) inside the worktree, I have to reinstall dependencies from scratch.
The official worktree docs already acknowledge this friction:

"Remember to initialize your development environment in each new worktree: install dependencies, set up virtual environments, or run whatever your project's setup requires."
— worktree docs

This is tolerable when worktree creation is a manual, occasional act. But in agent view, where worktree creation is automatic and per-session, the cost compounds: every dispatched session forces a full dependency reinstall before its output is runnable. A pnpm install on a non-trivial Next.js project takes 30–90 seconds and several hundred MB; multiply by N sessions per day and the friction is significant.
This problem isn't frontend-specific — it applies to any ecosystem with large local-only artifact directories: node_modules (npm/pnpm/yarn), .venv (Python), target/ (Rust), vendor/ (Go/PHP), etc.

Proposed Solution

A two-part fix, either of which would meaningfully improve the experience; ideally both:
Part A: Allow opting out of worktree isolation in agent view
Add a setting (CLI flag + settings.json key) to disable automatic worktree creation for agent view sessions. Suggested shape:
jsonc// .claude/settings.json or ~/.claude/settings.json
{
"agentView": {
"isolation": "worktree" | "none" | "ask"
}
}
Or as a CLI flag mirroring the existing pattern:
bashclaude agents --isolation none
claude --bg --isolation none "fix the dropdown bug"
isolation: none would run the dispatched session directly in the working directory, matching CLI default behavior. ask could prompt per dispatch for users who want case-by-case control.
This naming aligns with the existing isolation: worktree frontmatter option for subagents, suggesting the mechanism is already partly in place.
Part B: Reuse heavy dependency directories across worktrees
For users who want to keep isolation on, reduce the cost of each new worktree by automatically symlinking (or hardlinking) recognized dependency directories from the source checkout. Candidate list:

node_modules/ (and any nested ones, for monorepos)
.venv/, venv/, env/
target/ (Rust)
vendor/ (Go, PHP)
.next/, .nuxt/, dist/, build/ (build artifact caches, optional)

A reasonable heuristic: any directory that is (a) gitignored, (b) present in the source checkout, and (c) matches a known dependency-directory name, gets symlinked into the new worktree at creation time. This could be controlled by a setting:
jsonc{
"agentView": {
"linkDependencies": true,
"linkPatterns": ["node_modules", ".venv", "target", "vendor"]
}
}
Symlinks are the right primitive here: shared read access, no duplication, and if a session somehow needs to mutate dependencies it can detect and break the link.

Alternative Solutions

Manually run claude (CLI) without --bg: works, but loses the agent view organizational benefits, which are the reason I want to use it in the first place.
Run pnpm install after every dispatch: technically possible, but death-by-a-thousand-papercuts at scale.
Symlink node_modules manually after each worktree creation: requires a wrapper script and per-project setup; defeats the "just dispatch a task" UX of agent view.
Move dependencies to a shared store (pnpm's content-addressable store helps somewhat): pnpm partially mitigates the disk cost but pnpm install still needs to run, and npm/yarn users don't benefit.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

I am a frontend engineer working on internal tooling. Typical session:

Open agent view, dispatch a task: "fix the dropdown z-index bug in the settings page"
Claude runs in a new worktree, makes the edit, and reports it's done
I want to verify visually: start the dev server, click around, confirm the fix
But the worktree has no node_modules. I have to pnpm install (~60s + disk) before I can even run pnpm dev
Once verified, I want the change on my working branch — which requires a merge step that wouldn't have existed had Claude just edited my checkout directly

Additional Context

Environment
Claude Code: v2.1.139+ (agent view research preview)
Frontend stack: Next.js + pnpm (representative; the issue generalizes)