Have you heard about Jujutsu? If you haven’t start here: Use Jujutsu, Not Git

AI coding assistants like Claude Code are changing how we write software, but they also introduce a new challenge: managing the chaotic, experimental, and often parallel streams of work they generate. A common pattern is to run multiple Claude instances on different tasks, but orchestrating this with traditional Git can feel clunky, even with tools like git worktree.

This is where Jujutsu (jj) transforms from a ‘better Git’ into an essential tool for AI-driven development. As Maddie Mort explained in her ‘Jujutsu for Busy Devs’ [1] article , jj has a ‘significantly simplified mental model and command-line interface compared to Git, without sacrificing expressibility or power.’ That power is uniquely suited for the agentic workflow.

This guide will show you how to run parallel Claude sessions using two jj workflows, moving beyond simple isolation to effortlessly curating and stacking AI-generated code.

If you’re new to Jujutsu commands, the official Git command table provides a comprehensive mapping from Git commands you know to their JJ equivalents—an essential reference for navigating JJ’s powerful but different command structure.

Why Jujutsu is a Superpower for This Workflow

The design choices in jj that can seem strange to a seasoned Git user become superpowers when working with an AI agent.

1. Automatic Capture, Zero-Effort Committing: One of the most common hurdles for new jj users is that ‘all changes are always staged implicitly,’ as one HN commenter [2] noted. For an AI workflow, this is a feature, not a bug. Claude can generate dozens of files and changes; jj automatically captures everything in the current revision (@). You never lose work, and you don’t have to constantly run git add . to keep track. Claude’s workspace is a commit.

2. Zero-Cost Branching (Revisions): In Git, you might hesitate to create a new branch for a small experiment. In jj, creating a new revision with jj new is the default, zero-friction way to start a new line of thought. Each Claude session can live in its own revision without the overhead of branch management.

3. The Ultimate Safety Net: We’ve all been there: a wrong command or a messy rebase leaves you wanting to burn it all down. With jj, there’s a universal undo. Another HN commenter [3] put it perfectly:

   You can fuck up your repo in git and that’s it — you’re screwed… With jj you just jj op undo <operation_id_that_fucked_your_repo> and you’re fine.

4. Effortless Curation: Because Claude’s messy work is captured in a revision, you can act as a human curator. Many have asked, as this Lobsters user did [4], ‘How do you fit [a git add -p] workflow into jj?’ The answer, as another developer on HN explained [5], is to ‘use jj split to break changes apart.’ You can let Claude run wild, then surgically extract only the good parts into a clean, final commit.

5. No More Rebase Hell: Perhaps the most powerful feature is how jj handles stacked changes. Managing a series of dependent PRs is, in the words of yet another HN commenter [6], ‘excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change.’ With jj, this process is automatic, making it trivial to stack dependent tasks for your AI agent.

Method 1: The ‘Single Directory, Multiple Revisions’ Workflow

This is the most powerful and jj-native approach. You use a single directory and let jj manage the isolation between parallel tasks within its commit graph. It’s lighter and more fluid than worktrees.

Step 1: Set Up Your Workspace

First, get your repository ready for jj.

# Clone a new repo with jj
jj git clone --colocate git@github.com:your/project.git

# Or initialize jj in an existing repo
cd your-project
jj git init --colocate .

Step 2: Create a Revision for Each Claude Task

Instead of creating branches, you create distinct, parallel revisions off your main branch. Each revision is an isolated sandbox for a Claude session.

# Check your history to find the main branch
jj log

# Create a revision for Claude to refactor the auth system
jj new main -m "Claude Task: Refactor auth system"
# This creates a new, empty revision. Note its ID (e.g., 'abcde').

# Go back to main and create another, parallel revision for a new feature
jj new main -m "Claude Task: Build data visualization component"
# Note its ID (e.g., 'fghij').

Your jj log will now show two parallel revisions branching off main:

@  fghij...  (empty) Claude Task: Build data visualization component
│
○  abcde...  (empty) Claude Task: Refactor auth system
│
◆  main...   The main commit

Step 3: Run Claude in an Isolated Revision

You ‘enter’ a revision’s sandbox using jj edit. Your file system instantly updates to reflect that revision’s state.

Terminal Tab 1 (Auth Refactor):

# Check out the auth refactor revision to work on it
jj edit abcde

# The '@' symbol in 'jj log' now points to 'abcde'.
# Your working directory now reflects this revision.
# Start Claude. All file changes will be automatically part of this revision.
claude "Refactor the authentication system to use JWTs..."

Terminal Tab 2 (Data Viz Feature):

# In a new terminal, navigate to the same project directory
cd your-project

# Check out the data viz revision.
# This will instantly swap the files on your disk to this context.
jj edit fghij

# Start another Claude session. Its changes are isolated to *this* revision.
claude "Build a new data visualization component using D3.js..."

You can now switch between these contexts instantly in any terminal with jj edit <rev_id>. All of Claude’s work-in-progress is safely contained within its respective revision.

Method 2: The ‘Multiple Workspaces’ Workflow (The Worktree Equivalent)

If you need true filesystem isolation (e.g., for separate node_modules installations), jj has a direct equivalent to git worktree called jj workspace.

Step 1: Create a New Workspace for a Task

A workspace is a separate directory that shares the same underlying .jj repo but has its own working copy.

# From your main project directory
# Create a new workspace and a new revision for the task simultaneously
jj workspace add ../project-feature-a --rev "main" -m "Claude Task: Feature A"

This does two things:

1. Creates a new directory ../project-feature-a.
2. Creates a new empty revision named ‘Claude Task: Feature A’ off main and checks it out in that new workspace.

Step 2: Run Claude in Each Workspace

Terminal Tab 1 (Main Project):

cd your-project
claude "Fix bug #123"

Terminal Tab 2 (Feature A Workspace):

cd ../project-feature-a
# You must run dependency installation etc. here
npm install

# Run Claude in the isolated environment
claude "Implement Feature A..."

Uplevel: Curating and Stacking Claude’s Work

Now we combine the concepts to create a seamless human-AI collaboration workflow.

1. Curating Claude’s Messy Output

Claude has finished its ‘auth refactor’ (abcde). The revision now contains all the changes, good and bad. Here’s how to create a clean commit from the mess.

# Go to the revision Claude worked on
jj edit abcde

# Create a new, clean revision that will hold the final code
jj new @- -m "feat: implement JWT authentication"
# Let's say its new ID is 'xyz'.

# Now, use the interactive squash to pick the good parts from Claude's
# revision ('abcde') and move them into your clean one ('xyz').
# This is the super-powered 'git add -p'.
jj squash -i --from abcde

# After you're done, 'xyz' contains the clean changes.
# You can now abandon the messy "scratchpad" revision.
jj abandon abcde

2. Stacking Dependent AI Tasks

Imagine Claude needs to build a profile page that depends on the new JWT auth. You find a bug in the auth code after Claude has already started the profile page.

# 'xyz' is our clean JWT auth commit.
# Create a new revision for Claude on top of it.
jj new xyz -m "Claude Task: Build profile page"
# Let's say its ID is 'lmnop'.

# Run Claude in this new revision to build the page
jj edit lmnop
claude "Build the user profile page, using the new JWT auth..."

# OH NO! You find a bug in the original JWT auth commit ('xyz').
# With Git, this is where the pain begins. With jj, it's trivial.

# Edit the original commit directly
jj edit xyz

# Fix the bug (or have another Claude do it!)
# ...edit files...

# Now, here's the magic. Just go back to your latest work.
jj new lmnop

That’s it. Jujutsu automatically rebases the lmnop revision on top of the newly fixed xyz revision. No manual rebase needed. The problem that was once ‘excruciating’ is now solved implicitly.

By embracing jj’s revision-based model, you can elevate your work with AI from a series of disjointed prompts to a fluid, orchestrated, and safe development process.

References

1. Jujutsu for Busy Devs
2. One HN commenter
3. Another HN commenter
4. This Lobsters user did
5. Another developer on HN explained
6. Yet another HN commenter
7. Git command table - Jujutsu documentation