Scaling: Parallel Sessions, Teams, and Automation

Beyond One Claude, One Task

Everything covered in this track so far assumes one Claude Code session working on one task at a time. That is the right model for most individual development work. But Claude Code also scales horizontally. You can run multiple sessions in parallel, delegate different concerns to different sessions, use fresh contexts for independent code review, and integrate Claude into automated pipelines that run without your supervision.

This lesson covers the techniques for doing more with Claude Code: session management for multi-day work, parallel sessions for independent concerns, the Writer/Reviewer pattern for quality, non-interactive mode for automation, and managed deployment for teams.

Session Management

Claude Code saves every session locally. By default, sessions are unnamed and ordered chronologically. For work that spans multiple days — a long refactor, an ongoing feature, a complex bug investigation — naming and resuming sessions is the difference between coherent multi-session work and re-establishing context from scratch each time.

/rename my-session-name gives the current session a descriptive name. claude --continue resumes the most recent session. claude --resume opens a session picker so you can select from named sessions. Treat named sessions like branches: each significant workstream gets its own session that you can return to, pick up from where you left off, and close when the work is complete.

Sessions persist context including conversation history, file reads, and intermediate states. Resuming a session does not reload the full context window — it loads from the compacted summary of the earlier conversation and the recent messages. The longer the session, the more important it is to run /compact with useful instructions before ending a session you plan to resume.

Parallel Sessions and Worktrees

Multiple Claude Code sessions can run in parallel, each in its own git worktree. This prevents edit collisions when sessions are working on different parts of the codebase simultaneously. The desktop app manages multiple sessions visually, each in its own worktree. From the terminal, use git worktree add to create isolated checkout directories and start a separate Claude Code session in each.

Parallel sessions are valuable when you have genuinely independent workstreams — different features, different bug fixes, different parts of a migration. Each session has its own context window and its own file state. They cannot interfere with each other because they are in separate worktrees. When the work in one worktree is complete, merge it back to main and remove the worktree.

The Writer/Reviewer Pattern

A Claude session that writes code cannot give an independent review of that code. The session has the context of every decision that led to the implementation, which biases the review toward justifying those decisions rather than questioning them. A fresh session reviewing the same code has none of that context — it sees only the code and whatever criteria you provide, and gives a more honest assessment.

The Writer/Reviewer pattern uses two sessions:

• Session A (Writer): implements the feature
• Session B (Reviewer): reviews the implementation in a fresh context with no knowledge of how it was built

After Session A completes the implementation and creates a PR, start Session B and ask it to review the diff against specific criteria: does it implement all requirements, are the edge cases handled, is there anything that would fail code review? The review findings go back to Session A, which addresses them. This pattern catches more issues than self-review because the reviewer is genuinely independent.

The built-in /code-review skill automates the adversarial review step — it reviews the current diff in a fresh subagent and returns findings to the current session. For review against a plan document rather than general best practices, write the review prompt yourself with the plan as context.

Non-Interactive Mode

For CI pipelines, pre-commit hooks, and automated workflows, claude -p "your prompt" runs Claude without an interactive session. It processes the prompt, produces output, and exits. This is how you integrate Claude into build systems, deployment scripts, and monitoring workflows.

Output formats:

• claude -p "prompt" — plain text output
• claude -p "prompt" --output-format json — structured JSON including metadata
• claude -p "prompt" --output-format stream-json --verbose — streaming JSON for real-time processing

The --allowedTools flag scopes what Claude can do in non-interactive runs: --allowedTools "Edit,Bash(git commit *)" allows file edits and git commits but nothing else. This is important for automated runs where you do not want to grant Claude broad permissions without supervision.

For uninterrupted execution with background safety checks, --permission-mode auto enables auto mode. A classifier model reviews commands before they run, blocking scope escalation, unknown infrastructure changes, and hostile-content-driven actions while letting routine work proceed without prompts. Auto mode aborts non-interactive runs if the classifier blocks actions repeatedly, since there is no user to fall back to.

Fan-Out Automation

For large-scale tasks — migrating 500 files to a new pattern, analyzing an entire codebase for security issues, running the same transformation across many independent inputs — fan-out loops distribute work across parallel Claude invocations:

for file in $(cat files-to-migrate.txt); do
claude -p "Migrate $file from the old auth pattern to the new one. Return OK or FAIL."
--allowedTools "Edit,Bash(git add *,git commit *)" &
done
wait

Test on a small sample first. Refine the prompt based on what goes wrong with the first 5-10 files. Then run at scale. The --allowedTools flag is critical in fan-out automation: it limits blast radius if something goes wrong with one invocation.

Managed CLAUDE.md for Teams

Organizations can deploy CLAUDE.md files that apply to every Claude Code session on every developer machine — regardless of the project or working directory. These managed policy files are placed at system-level paths:

• macOS: /Library/Application Support/ClaudeCode/CLAUDE.md
• Linux/WSL: /etc/claude-code/CLAUDE.md
• Windows: C:Program FilesClaudeCodeCLAUDE.md

Alternatively, embed CLAUDE.md content directly in managed-settings.json using the claudeMd key — useful when you are already distributing managed settings via MDM or Group Policy and want to avoid deploying a separate file.

Managed policy CLAUDE.md files cannot be excluded by individual claudeMdExcludes settings. They always apply. Use them for compliance requirements, security policies, and behavioral guidelines that must reach every developer. For project-specific standards, use a committed project CLAUDE.md instead — managed policy is for organization-wide concerns that apply across all projects and repositories.

The distinction between managed settings and managed CLAUDE.md is important: settings are for technical enforcement (blocking tools, enabling sandbox, routing API calls), while CLAUDE.md is for behavioral guidance (code style, data handling reminders, workflow preferences). Settings are enforced by the client; CLAUDE.md is advisory context that Claude reads and tries to follow.