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 jj-native approach for keeping multiple task revisions in the commit graph while working from one directory. It is useful when you want to switch between tasks quickly and let jj track each task as its own revision.

It is not true parallel filesystem isolation. I verified this locally with jj 0.32.0: after creating two revisions with different contents, jj edit <rev> kept the same current working directory and swapped the files on disk to that revision’s contents. A single jj workspace has one working copy. If you want multiple Claude sessions running at the same time against separate files, dependencies, or build artifacts, use the multiple workspaces workflow below.

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 line of work in jj’s history.

# 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: Switch Into a Revision

You switch the current workspace to a revision using jj edit. Your file system updates to reflect that revision’s state.

This isolates the work in jj’s history model, not in a separate directory. Other terminals pointed at the same project directory will see the same file changes when the working copy moves.

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..."

To work on the second task, stop or pause the first Claude session, then switch the same working copy:

# Switch the current workspace to the data viz revision.
# This swaps the files on disk to that revision's context.
jj edit fghij

claude "Build a new data visualization component using D3.js..."

You can switch between these contexts with jj edit <rev_id>. Claude’s changes are kept in the selected revision, but the filesystem is still shared by this one workspace. For concurrent Claude sessions, use separate jj workspaces.

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

If you need true filesystem isolation, especially for multiple Claude sessions running concurrently, use jj workspace. This is the jj equivalent of git worktree: each workspace gets its own directory, working copy, dependencies, and build artifacts while sharing the same underlying repo history.

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 whose working-copy revision is based on main.
jj workspace add ../project-feature-a --revision main --name feature-a

cd ../project-feature-a
jj describe -m "Claude Task: Feature A"

This does two things:

1. Creates a new directory ../project-feature-a.
2. Creates a new working-copy revision based on main in that directory. You can then describe it, run installs, and launch Claude there without moving the files in your original 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
# Run dependency installation etc. here
bun 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