DEV Community

Cover image for Parallel work with Claude Code in iTerm2 - a workflow inspired by Boris Cherny
Kamil Buksakowski
Kamil Buksakowski

Posted on

Parallel work with Claude Code in iTerm2 - a workflow inspired by Boris Cherny

A while ago, Boris Cherny's setup for working with Claude Code went viral. I noticed how he works in parallel across several terminals and how much it simplifies context management.

In this article, I'm showing a workflow inspired by Boris's setup, extended with Git worktrees for real work without conflicts. I'm still testing this workflow in practice, but it already works well enough to be a valuable starting point for others. That's why this tutorial exists.


Installation

brew install --cask iterm2
Enter fullscreen mode Exit fullscreen mode

Open iTerm2 via Spotlight (⌘ + Space, type "iterm").

After launching, you'll see:

Creating tabs

Create several tabs with the shortcut:

⌘T
Enter fullscreen mode Exit fullscreen mode

Repeat 5 times (or as many as you need).

Switching between tabs:

  • ⌘1 – first tab
  • ⌘2 – second tab
  • ⌘3 – third tab

By default, all tabs have the name -zsh, which quickly becomes hard to read.

Boris's setup looks much cleaner – each tab has a simple, numbered name.


Numbering tabs

Double-click the name of the first tab (where it says -zsh).
A Set Tab Title window will appear.

Type the tab number (e.g., 1 for the first, 2 for the second) and click OK.

On the screen:

  • red circle 1 – double-click the tab name
  • red circle 2 – type the number and confirm

Repeat the operation for the remaining tabs (2, 3, 4, 5, …).

Final result:


Simple flow for small tasks

Simplest approach: one tab = one branch.

Before running Claude Code:

git checkout -b feature/auth
Enter fullscreen mode Exit fullscreen mode

then:

claude
Enter fullscreen mode Exit fullscreen mode

This approach works well for small, independent tasks in different parts of the project.

Keep in mind that when running the same project in several terminals, Claude Code works on the same file state. If tasks start touching similar code areas, conflicts can appear. That's why we use this approach consciously and only for simple cases.

Here's how it looks for me:


Extended flow for larger tasks

When working on larger features or several tasks in parallel, just switching branches in one directory quickly becomes inconvenient.

Problem

Claude Code operates on the filesystem state of a given folder, regardless of the current branch. Even if we have different branches open in several terminals, we're still working on the same working directory, which increases the risk of conflicts.

Solution

Git worktrees – multiple working directories, no conflicts.

Setup Git Worktrees:

1. Creating worktrees (e.g., at the start of the day)

cd ~/projects/my-super-project
Enter fullscreen mode Exit fullscreen mode
git worktree add ../worktrees/task1 -b feature/carrier-popup
git worktree add ../worktrees/task2 -b feature/email-validation
git worktree add ../worktrees/task3 -b feature/carrier-filters
Enter fullscreen mode Exit fullscreen mode

2. Running Claude Code in each worktree

# Tab 1
cd ~/projects/worktrees/task1
claude "Task 1 description"

# Tab 2
cd ~/projects/worktrees/task2
claude "Task 2 description"

# Tab 3
cd ~/projects/worktrees/task3
claude "Task 3 description"
Enter fullscreen mode Exit fullscreen mode

Each terminal now works on a separate folder and a separate branch.

3. Finishing feature and cleanup

After finishing work and code review:

# In each worktree
git add .
git commit -m "feat: change description"
git push origin feature/branch-name
Enter fullscreen mode Exit fullscreen mode

Removing worktrees:

# In main repo
cd ~/projects/my-super-project
git worktree remove ../worktrees/task1
git worktree remove ../worktrees/task2
git worktree remove ../worktrees/task3
Enter fullscreen mode Exit fullscreen mode

Notes

  • Worktrees outside repo (../worktrees/) → do not require .gitignore
  • Each worktree = separate branch = separate changes
  • Each worktree has its own node_modules, but shares .git – operations on the repo are shared

Notifications in iTerm2

After Claude Code finishes a command, you can get a notification (sometimes with a slight delay).

Open iTerm2 settings:

⌘ ,
Enter fullscreen mode Exit fullscreen mode

Then:

  1. Profiles (top bar)
  2. Terminal (right panel)
  3. Check:
    • ✓ Flash visual bell
    • ✓ Show bell icon in tabs
    • ✓ Notification Center Alerts

Additionally, in System Settings (macOS):
Settings → Notifications → iTerm2 → Allow

Result:

BONUS – keyboard shortcut conflict

If you use Command + Right Arrow in Claude Code to jump to the end of a line, iTerm2 might switch tabs.

To disable this:

1) Open settings:

⌘ ,
Enter fullscreen mode Exit fullscreen mode

2) Go to Keys
3) Find: Previous Tab and Next Tab
4) Set both to "-" (minus = disabled)

Now Command + Right Arrow works correctly in Claude Code.


Summary

Numbered tabs, conscious use of branches, and Git worktrees let you work sensibly in parallel with Claude Code without fighting with context and code conflicts.

This is a workflow that works especially well when working on multiple tasks at the same time.

Happy coding! 🚀

Top comments (0)