Parallel Tasks: Let Multiple Claudes Work Simultaneously Instead of Queuing

📚 Series Navigation: The previous article 40 Chrome: Letting It Operate the Browser taught you how to extend Claude's reach into the browser, clicking pages and filling forms automatically. This article shifts to another dimension—instead of having a single Claude do multiple tasks, we let several tasks start simultaneously. Git worktree isolation, background multi-sessions, and headless batch runs will all be explained in one go, along with the most critical rule: when parallel tasks actually save time, and when they just make a mess.

It's a bit embarrassing to admit, but the first time I wanted to "work in parallel," I did something really stupid: I opened two terminals, cd'd both into the same project directory, and had Claude modify the frontend login page in one while having it fix a backend bug in the other.

I felt pretty smug thinking, "This is double the efficiency!"

The result—both sides were modifying package.json, and the dependency just added on one side was directly overwritten and rolled back by the edits from the other; running git status showed the workspace was a complete mess, and it was impossible to tell who edited which line. I spent far more time that day manually untangling the changes than I would have by "patiently doing things one by one", getting more frustrated by the minute. It was then that I realized: parallel tasks are not as simple as "opening multiple windows"—the core is "not letting them step on the same ground."

In fact, Claude Code has long prepared proper parallel tools—--worktree to give each session an isolated copy of the code, --bg to dispatch tasks to the background for batch execution, and claude agents to provide a central console to monitor them. In this article, we'll fill that pitfall completely and guide you through running these methods yourself.

After reading this article, you will get:

• A brief explanation of "why parallelize," and the two prerequisites: tasks must be independent and must not contest the same files
• A comparison table of the four official parallel methods (subagent, agent view, agent teams, dynamic workflows) to help you choose the right one
• How to use --worktree to give each session an isolated copy, avoiding overwriting—along with tips on .worktreeinclude and cleanups
• How to use claude agents and --bg to push tasks to the background, monitoring progress on a single screen and intervening only when necessary
• How to use claude -p (headless mode) to run tasks in scripts in batches, using --bare for faster startup
• The most important dividing line: when it is worth parallelizing, and when it just gets you tangled up

---

01 Think Clearly First: What Problem Does Parallelizing Solve, and What Is the Prerequisite?

Conclusion first: parallelizing solves the problem of "several unrelated tasks that you don't want to wait for sequentially"; but it only works on one prerequisite—these tasks must not contest the same files.

Looking back at the previous 40 chapters, we basically worked within "a single session"—starting one Claude, giving instructions, and letting it work step-by-step. This mode is sufficient for 90% of tasks. But there are two situations where you will find it slow.

First, when tasks are naturally separate and independent. For example, "editing frontend styles," "fixing a backend bug," and "adding unit tests" have nothing to do with each other, but they must queue up: the backend bug is fixed only after the frontend changes are done. They could easily be run simultaneously, but are forced to run sequentially.

Second, when a task is too large for a single session to handle. For instance, "replacing an old API with a new one across the entire codebase" involves dozens or hundreds of files. Running a single session from start to finish will quickly fill the context window (its "working memory", detailed in Chapter 19), making it "forget things" the further it goes.

Analogy: Checkout lines at a supermarket. If there's only one cashier, a long queue of ten people with carts means the tenth person must wait for the first nine to check out—that is sequential execution. A smart supermarket will open multiple registers, splitting the ten people into three or four lines to check out simultaneously, cutting down the total wait time. Parallel work is like "opening multiple registers": assigning separate tasks to multiple Claudes to work in parallel, instead of queuing up in a single line.

But opening multiple registers has an implicit prerequisite: each line must be independent and not interfere with the others. If three cashiers shared a single cash drawer, putting money in and taking change out simultaneously, it would immediately get messy—which is exactly the pitfall at the beginning. Thus, the ironclad rule of parallel execution is:

Do tasks touch the same files? Use worktrees to isolate work.

In real scenarios, tasks that can run in parallel look like this:

• "Fixing bugs in three unrelated modules respectively"—remedying them in three parallel sessions without mutual interference
• "Scanning for unused dead code across the utils/ directory"—spawning a subagent to search it, keeping the main conversation from being cluttered with files (see Chapter 23)
• "Running the same script modification across 30 files"—writing it as a headless batch task and letting the machine run it automatedly

💡 Summary in one sentence: Parallelizing is to make independent tasks run without queuing (like opening multiple checkout registers), but the ironclad rule is: never let them contest the same files, otherwise parallelizing only leads to chaos.

---

02 The Four Official Parallel Methods: Get Familiar First

Claude Code supports multiple parallel methods. The official "Running Agents in Parallel" page compares them side-by-side. The core difference boils down to a single question: who coordinates the work? Is it Claude delegating and gathering tasks within a conversation, you dispatching them to check back later, or Claude acting as a foreman supervising a team?

Let's get familiar with the four methods in a table. This section is a map, while the following sections drill down into the details:

Method	What it is	Who coordinates	When to use
Subagent	A worker dispatched within a session that performs work in its own context and returns a summary	Claude delegates and gathers tasks in the chat	When auxiliary tasks would fill the main chat with search results/logs, and you don't need to read the process details
Agent view (Research Preview)	A screen to schedule and monitor multiple background sessions, opened via claude agents	You dispatch tasks and check back later	When you have several independent tasks to delegate, want to check status at a glance, and intervene only when needed
Agent teams (Experimental, default off)	Multiple sessions coordinating work, sharing task lists, sending messages, with a leader supervising	Claude acts as a foreman supervising the team	When you want Claude to split a project, assign parts, and keep workers in sync (see Chapter 29)
Dynamic Workflows (Research Preview)	A script running a large batch of subagents and cross-verifying results	The script, rather than Claude checking step-by-step	When tasks are too large for a few subagents to coordinate, or require cross-verification: repository audit, migrating 500 files

⚠️ Experimental Labels: In the table above, agent view and workflows are research previews, and agent teams is experimental and disabled by default—UI, shortcuts, and behaviors are subject to change. Run claude --version first to verify your version. Subagents are a stable feature.

You don't need to memorize this table; just remember: "who coordinates" is the watershed—Claude delegating inline → Subagent; you dispatching to background → Agent view; Claude acting as foreman → Agent teams; script running batch files → Workflows.

There are two other tools that are not parallel methods themselves, but support parallel execution, and this article focuses on the former:

• Worktrees: Give each session a separate git worktree, preventing parallel sessions from modifying the same files. This is the solution to the pitfall at the beginning, explained in Section 03.
• /batch: A skill that lets Claude split a large change into 5 to 30 subagents isolated by worktrees, with each opening a PR. It is a packaged usage of "subagent + worktree", not a separate coordination style.

Subagents (Chapter 23) and Agent teams (Chapter 29) have been discussed in detail, so they won't be repeated here—this article focuses on what hasn't been touched: worktree isolation, background multi-sessions, and headless batch execution.

💡 Summary in one sentence: There are four official parallel methods, with "who coordinates" as the key distinction; worktree and /batch are supporting tools; this article focuses on worktree, background sessions, and headless execution.

---

03 Worktree Isolation: Give Each Session "Its Own Copy"

This section is the solution to the pitfall at the beginning, and the most critical part to understand.

Let's analyze why the starting scenario failed: opening two sessions inside the same directory is like two people drawing on the same paper simultaneously; edits overwrite each other, causing chaos. Git worktree (a native git capability) is the cure for this.

Analogy: Photocopying a blueprint, letting each person edit their own copy. If there is only one master blueprint and three people need to annotate it, doing so on the same paper results in a mess. The correct way is to make three photocopies—each person gets a copy to modify freely, and the changes are merged later. Git worktree does exactly this: it checks out separate working directories from the same repository history, each with its own files and branches, but sharing the same commit history and remotes. Modifications in one session's copy never affect the files of another session.

The official documentation highlights this valuable point:

Running each Claude Code session in its own worktree means edits in one session never touch files in another, so you can have Claude building a feature in one terminal while fixing a bug in a second.

Open an Isolated Session in One Command

The simplest usage: append --worktree (or short flag -w) when starting, followed by a name. Claude will automatically create an isolated worktree and start working in it. By default, this worktree is located in .claude/worktrees/<name>/ under your repository root, with a branch named worktree-<name>:

claude --worktree feature-auth

Want to start a second independent session? Open another terminal, use a different name, and run the same command:

claude --worktree bugfix-123

Now the two sessions reside in their own copies, one building features and the other fixing bugs, without touching each other's files—completely avoiding the "overwriting" disaster. Too lazy to name it? Omit the name, and Claude will automatically generate one like bright-running-fox:

claude --worktree

You can also request it to enter a worktree during a session—simply say "work in a worktree", and it will use the EnterWorktree tool to create one for you.

Before running --worktree in a directory for the first time, you must run a normal claude session in that directory first and accept the workspace trust dialog. If trust has not been accepted, --worktree will fail and ask you to run claude first—this applies to -p mode as well.

Three Common Pitfalls for Beginners

Pitfall 1: .claude/worktrees/ must be added to .gitignore. Otherwise, these worktree directories will show up in your main directory as "untracked files", cluttering things. The official docs specifically highlight this.

Pitfall 2: The worktree is a clean checkout, so your .env files are not copied. Since a worktree is a clean checkout, untracked files in the main repository (like .env, .env.local) are not copied over by default—causing the new session to fail due to missing environment variables. The solution is to place a .worktreeinclude file in the project root, listing local files that should be automatically copied into each worktree, using the same syntax as .gitignore:

.env
.env.local
config/secrets.json

I personally tripped over this pitfall: I started a session with -w to modify the backend, but Claude kept reporting database connection failures. I spent a long time troubleshooting, even questioning if the database was down—only to realize that .env wasn't copied into the worktree, and the connection string was missing. Since then, I place a .worktreeinclude in the root of every project, and have never run into this issue again.

Pitfall 3: Decide whether to "keep or delete" upon exit. The official cleanup rules are straightforward:

• If nothing was changed (no uncommitted changes, no untracked files, no new commits): the worktree and its branch are automatically deleted; however, if the session was named (--name), Claude prompts you to keep or delete.
• If things were changed: Claude will prompt you to "keep or delete"—keeping preserves the directory and branch so you can resume later, while deleting discards the worktree along with uncommitted changes.
• Worktrees created in non-interactive (-p) mode are not automatically cleaned up since there is no exit prompt, so you must run git worktree remove manually.

Manual Setup If You Don't Want Automatic Worktrees

If you want complete control over where the worktree is placed or which branch it uses, you can create it manually via git (explained in Chapter 43 on Git workflows):

# Create a worktree on a new branch
git worktree add ../project-feature-a -b feature-a

# Enter and start Claude
cd ../project-feature-a && claude

# List all worktrees
git worktree list

# Remove when done
git worktree remove ../project-feature-a

The official docs remind you of one thing that is easy to forget: each new worktree is an independent checkout, so remember to reinstall dependencies and configure virtual environments—don't expect it to inherit the node_modules from the main directory.

💡 Summary in one sentence: Worktree provides each session with an independent copy of the code (like photocopying a drawing to edit separately); run claude --worktree <name> to start an isolated session; remember the three pitfalls: add .claude/worktrees/ to .gitignore, copy .env via .worktreeinclude, and choose "keep/delete" on exit.

---

04 Multi-session Parallelism: Background Dispatch + A Central Console

Worktrees solve the file contest issue, but another problem remains: if you start three or five sessions, do you have to open three or five terminals and switch back and forth to monitor each? That's too tedious. This is where "agent view" comes in.

Analogy: Flight status board in an airport control tower. The tower doesn't assign one person to stare at a single aircraft—instead, a large screen displays the status of all flights at a glance: taxiing, waiting, or landed. The controller checks the overview periodically and only takes over communication when a specific pilot needs a decision. claude agents provides this control tower screen: listing all background sessions in rows so you can scan their status at a glance, intervening only when needed.

⚠️ Research Preview: Agent view is marked as a research preview. It requires a recent version of Claude Code; the UI and shortcuts may change. Check your version with claude --version first.

Dispatching Tasks to the Background

The essence of background sessions is: they are not tied to your terminal—even if you close the screen, exit the shell, or open another interactive session, they keep running. There are a few ways to dispatch them.

Method 1: Dispatch directly from the shell using --bg:

claude --bg "Investigate why the SettingsChangeDetector test is flaky"

Once dispatched, Claude prints the short ID of the session and commands to manage it, looking roughly like this:

backgrounded · 7c5dcf5d
  claude agents             list sessions
  claude attach 7c5dcf5d    open in this terminal
  claude logs 7c5dcf5d      show recent output
  claude stop 7c5dcf5d      stop this session

Method 2: Dispatch from an active chat by typing /bg (short for /background) to move the current conversation to the background.

Manage Them Using the claude agents Console

Open the console:

claude agents

It occupies the terminal and lists all background sessions grouped by status—categorized into "Input Needed," "Working," and "Completed." An icon at the start of each row shows the session status via color and animation:

Status	Icon	Meaning
Working	Animated flashing	Running tools or generating a response
Input Needed	Yellow	Waiting for your input or permission approval
Completed	Green	Task completed successfully
Failed	Red	Terminated with errors

The console has three core operations, and memorizing these is enough for beginners:

• Space (Peek): Select a row and press spacebar to pop up a panel showing its recent output or what problem it is stuck on—usually, you just need a quick glance instead of opening the full conversation.
• Reply: Type directly in the peek panel to reply and press Enter to send, without leaving the console.
• Enter / → (Attach): To jump into a specific session for a detailed chat, press Enter to "attach", turning it into a full interactive session; press ← in the empty input box to return to the console.

Here is a hidden but crucial detail that connects with the worktree section: before making file edits in a background session, Claude automatically moves the session into an isolated worktree under .claude/worktrees/. This means—when using agent view to parallelize tasks, file isolation is handled automatically, without you having to manually run -w like in Section 03. The official documentation confirms that agent view automatically creates an independent worktree when dispatching each session.

Consider a common parallel combination: dispatching three background sessions simultaneously—one to fix a flaky test, one to review a PR, and one to write documentation. You can continue other work, checking claude agents periodically—verifying when a row turns green, or approving when it turns yellow. It is much easier than switching between three terminals.

⚠️ A billing reality: Background sessions consume your subscription usage just like interactive sessions. Running ten in parallel consumes quota roughly ten times faster than running one. Don't start a huge pile just because they run in the background.

💡 Summary in one sentence: --bg dispatches tasks to the background, /bg moves the current session to the background, and claude agents provides a flight-board-like console—press Space to peek, type to reply directly, or press Enter to attach; file isolation for background sessions is automatically handled via worktree, but running more parallel tasks drains your quota faster.

---

05 Headless Batch Execution: Scripting and Running Unattended

The previous two methods involve you monitoring at the terminal. But there's a category of tasks you don't want to watch at all—running the same routine across a batch of items; or integrating Claude into CI or scripts, letting it be invoked automatically like a command-line utility. This is headless mode (running without an interactive interface, exiting immediately upon completion).

Analogy: Writing instructions on a slip, dropping it in a vending machine, and taking the output. You don't stand in front of a vending machine watching it process—insert coins, press buttons, the item drops, and you leave. Headless is this "unattended" process: you write instructions and parameters all at once, feed them to claude -p, and it exits after spitting out the results for you to use.

The core is the -p (or --print) flag. With it, claude runs non-interactively once and exits:

claude -p "Find and fix the bug in auth.py" --allowedTools "Read,Edit,Bash"

Here, --allowedTools pre-approves the tools it can use—since no one is there to click "agree", you must tell it beforehand "you can use these tools freely, don't pause to ask" (permission modes are detailed in Chapters 20 and 35).

Three Supporting Features to Make It Useful

Feature 1: Piping data. Headless mode reads standard input (stdin), so you can pipe data into it just like any command-line tool. For example, piping a build error for explanation and writing the output to a file:

cat build-error.txt | claude -p "Briefly explain the root cause of this build error" > output.txt

When troubleshooting a failed build, tossing it over in a single line is much faster than copy-pasting the error into a session.

Feature 2: --bare for faster startup. By default, claude -p loads the same context as an interactive session (scanning hooks, skills, plugins, MCP, and CLAUDE.md), which is slow in scripts and might be affected by configurations in a teammate's ~/.claude. Adding --bare skips these automatic discoveries, booting faster and producing consistent results across machines:

claude --bare -p "Summarize this file" --allowedTools "Read"

The official documentation states:

--bare is the recommended mode for script and SDK calls, and will become the default for -p in future versions.

Feature 3: --output-format json for structured results. Plain text is hard to parse in scripts. Adding --output-format json returns structured JSON with metadata (result, session ID, and total_cost_usd showing the cost of the run), which can be extracted easily using jq:

claude -p "Summarize this project" --output-format json | jq -r '.result'

Combine Headless into "Batch Runs"

A single -p run is not a batch. True batching involves wrapping it in a shell loop—running the same task across a set of files. For example, generating a one-line description for every .py file under a directory:

for f in src/*.py; do
  claude --bare -p "Describe what $f does in one sentence" --allowedTools "Read"
done

This is the basic template for "unattended batching": loop, -p, and --bare. Of course, if the task involves dozens or hundreds of files and requires cross-verification of results, you should upgrade to the dynamic workflows or /batch mentioned in Section 02—which formally engineer this batch execution.

⚠️ A billing update to note: The official documentation states that starting June 15, 2026, usage of the Agent SDK and claude -p under subscription plans will be billed from a separate monthly Agent SDK quota, distinct from your interactive usage. Keep this in mind before running batch scripts (billing details in Chapter 06).

💡 Summary in one sentence: Headless uses claude -p to run non-interactively once and exit (like a vending machine requiring no supervision), paired with --allowedTools to pre-approve tools, --bare to speed up, and --output-format json to get structured output; wrapping it in a shell for loop forms the basic template for batching.

---

06 The Most Critical Section: When NOT to Parallelize

We explained three parallel approaches, but this section is more important than the rest—because many people get overly excited once they learn about parallelism, trying to split everything, only to end up with more chaos, higher costs, and messy histories.

Let's draw the line of judgment. To make parallelizing worthwhile, two conditions must be met simultaneously: tasks must be independent (A does not depend on B's output) and must not contest the same files (or must be isolated via worktree). If either is missing, parallelizing is just digging a hole for yourself.

Let's compare what should be parallelized and what should be run sequentially:

Scenario	Should you parallelize?	Why
Fixing bugs in three unrelated modules respectively	✅ Parallel	Independent, no file contests; classic case for parallelism
Running the same change across 30 files in batch	✅ Parallel (headless / /batch)	No mutual dependencies, letting the machine handle it is most efficient
"Refactoring A first, then modifying B based on the new A"	❌ Sequential	B depends on A's results; parallelizing will only give B the old version of A
Two sessions both need to modify package.json	❌ Sequential (or isolate with worktree)	Contesting the same file, which is exactly the starting pitfall
A small change taking five minutes to complete	❌ Sequential	The coordination overhead of splitting exceeds the saved time
Tasks needing frequent exchange of intermediate results	⚠️ Case-by-case	High communication overhead, better to run sequentially in one session

Here are three practical rules learned from experience to keep in mind:

First, never parallelize tasks with sequential dependencies. For instance, "refactoring the core module, then adapting other modules to the new interface"—the latter step must wait for the former. Forcing them into parallel execution causes the latter to edit based on the old version, rendering the work useless once completed. Doing this wastes the quota of two sessions.

Second, don't split small tasks. If a task takes five minutes to finish, the time spent "thinking about how to split it, starting sessions, and merging back" will exceed five minutes. Splitting tasks has an overhead, and splitting small tasks is a net loss.

Third, running more in parallel burns quota faster. Let's emphasize Section 04's point again: running ten sessions in parallel consumes quota roughly ten times faster. A safe habit is—keep manual parallel sessions within three to five; for massive batches (dozens or hundreds), delegate them to /batch or dynamic workflows instead of manually opening a screen of sessions.

Simply put, parallelism is a double-edged sword: in the right scenarios, it multiplies efficiency; in the wrong ones, it is slower, costlier, and messier than sequential execution. Judging "whether to parallelize" is always more valuable than knowing "how to parallelize."

💡 Summary in one sentence: The ironclad rule for parallelizing is "independence + no file contests"; do not split tasks if either is missing; do not parallelize tasks with sequential dependencies or small 5-minute tasks; parallel runs consume more quota, so keep manual sessions within three to five, delegating larger batches to /batch.

---

07 Action: Run Worktree Isolation + Background Tasks Yourself

Theory is nothing without practice. The following routine is based on a git repository; if you don't have one, create a temporary repo to practice. The commands are runnable, and each step provides expected output. Follow along to build muscle memory.

A git repository is required; the background sessions part requires a recent version of Claude Code (agent view is a research preview). Check your version with claude --version first. The commands below do not require a VPN.

Step 1: Enter a git project, and accept the trust dialog first

cd your-git-project
claude

Go in, ask a random question (like "what does this project do?"), and exit. This step is to accept workspace trust—otherwise, the next --worktree step will throw an error.

Step 2: Start an isolated session using --worktree

claude --worktree test-parallel

Expected: Claude creates an isolated worktree under .claude/worktrees/test-parallel/ and starts inside it. Any file edits in this session only affect this copy, keeping the main directory untouched. On exit, if modifications were made, it asks you to "keep or delete"—choose delete for practice.

Step 3: Confirm the worktree is created (open another terminal, return to the main project directory)

git worktree list

Expected: In addition to the main checkout, an extra row appears pointing to .../.claude/worktrees/test-parallel with its own branch. Seeing this row confirms the isolated copy is created.

Step 4: Dispatch a task to the background

claude --bg "List the titles of all markdown files in this project"

Expected: The terminal prints a line backgrounded · <short-ID>, followed by management commands like claude attach, claude logs, and claude stop. Seeing this means the task is running in the background, freeing up your terminal immediately.

Step 5: Open the console to monitor it

claude agents

Expected: The terminal is occupied by agent view, and the session you just dispatched appears as a row, marked with its status (Working / Completed). Select it and press Space to peek at its output, press Esc to close the panel, and press Esc again to exit agent view. Seeing this list means you can manage multiple background sessions from a single screen.

Step 6: Cleanup

# Stop the background session (replace short-ID with the one printed in Step 4)
claude stop <short-ID>

# Delete the practice worktree (in the main project directory)
git worktree remove .claude/worktrees/test-parallel

Expected: claude stop prints a stop confirmation; running git worktree list after git worktree remove shows that the test-parallel row is gone. Clean cleanup = complete workflow verified successfully.

Running these six steps walks you through the core parallel workflow: "start isolated session → verify copy → dispatch to background → monitor via console → cleanup." Any future parallel work follows this exact routine, just with different tasks and more sessions.

💡 Summary in one sentence: The practical workflow has just six steps—run claude (to accept trust) → start an isolated session via --worktree → run git worktree list to confirm → dispatch to background via --bg → monitor with claude agents → clean up with stop + git worktree remove; running it once is more effective than memorizing ten commands.

---

08 Summary

This article discussed "letting multiple Claudes work simultaneously," starting from "why parallelize" to "when not to parallelize," covering three practical methods along the way.

Let's review the core points:

What you want to do	What to use	Key points
Understand what parallelizing solves	The two prerequisites: "independence + no file contests"	Like opening multiple checkout registers, but each line must be independent
Identify parallel methods	Four methods in a table	"Who coordinates" is the watershed; agent view / workflows are research previews, teams is experimental
Prevent sessions from overwriting files	--worktree / git worktree	Provide each session with an independent copy; watch out for .gitignore, .worktreeinclude, and cleanup pitfalls
Dispatch to background and monitor status	--bg + claude agents	Background sessions are not tied to the terminal; file isolation automatically uses worktree; Space to peek, Enter to attach
Scripting tasks for batch execution	claude -p (headless)	Pair with --allowedTools for pre-approval, --bare to speed up, and --output-format json to get structured output
Determine when to parallelize	Ironclad rule: "independence + no file contests"	Avoid for tasks with sequential dependencies or small tasks; parallel runs consume more quota, so keep within 3-5 sessions

You should now be able to: understand what parallelizing solves and its ironclad rule ("independence + no file contests"); distinguish the four official parallel methods; use --worktree to open isolated copies for sessions, avoiding the "overwriting" disaster; use --bg and claude agents to dispatch tasks to the background and monitor them on a single screen; run claude -p in scripts for batch runs; and most importantly—calmly judge whether a task is worth parallelizing instead of splitting blindly.

Looking back at the stupid mistake of "modifying the same directory in two terminals," the root cause was not understanding isolation or dependencies. Now you have the key of worktree isolation and the dividing line of judgment, saving you from taking a long detour.

---

The next chapter 42 "Environment Variables"—you've already run into several environment variables in this article: CLAUDE_CODE_SIMPLE behind --bare, CLAUDE_CODE_DISABLE_BACKGROUND_TASKS that disables background tasks, and CLAUDE_CONFIG_DIR that overrides configuration paths... They are like a row of hidden toggle switches, not obvious, but capable of quietly altering Claude Code's behavior. The next chapter will unpack this row of switches, showing what each does and which are worth tweaking. Think about it: the same command might behave differently on your local machine versus in a CI pipeline—and the difference often lies in these environment variables.

---

Recommended Reading

• How to Ask and Give Instructions: Speak Directly to Claude's Core
• Glossary (Beginner-Friendly): Translating the Jargon into Plain English
• GitHub Actions: Mentioning Claude in a PR to Let It Work Independently