I prefer Jujutsu (jj) over Git for version control, but getting Claude Code to work with jj proved tricky since Claude Code defaults to git. This post explains how to configure Claude Code to use jj instead of Git for version control operations and file change detection.

I'll show you three possible approaches to get Claude Code working properly with Jujutsu repositories, from simple configuration changes to advanced system prompt modifications.

Quick Solution: CLAUDE.md Configuration

For most users, this addition to your project's CLAUDE.md file should configure Claude Code to start using Jujutsu:

## Version Control

**CRITICAL: This repository uses Jujutsu (jj), not git.** Always use `jj` commands for version control operations.

- Use `jj st --no-pager` to check status (like `git status`)
- Use `jj log --no-pager` to view history (like `git log`)
- Use `jj commit -m "message"` to create commits (like `git commit`)
- Use `jj split -m "message" file1 file2` to commit specific files only
- Use `jj bookmark set main -r @- && jj git push` to push to remote repository

- ALWAYS check for any sensitive information that shouldn't be committed

The CLAUDE.md file contains instructions that Claude Code reads for each project.

Before I came up with this configuration I tried quite a number of different instructions. I suspect this one works because of the combination of:

  • The 'CRITICAL' keyword: Signals high priority to Claude Code's instruction processing

  • Explicit repository type declaration: Removes ambiguity about which version control system to use

  • Specific jj command mapping: Provides concrete alternatives to built-in Git commands

You can expand the command list to match your workflow, but these core commands worked for me and should get you started.

Why Claude Code uses Git

Claude Code has Git instructions hardcoded into its system promp, the internal directions that override user preferences. Here is part of the Git configuration in the system prompt from Claude Code 1.0.85:

# Committing changes with git

When the user asks you to create a new git commit, follow these steps carefully:

1. You have the capability to call multiple tools in a single response. When multiple independent pieces of information are requested, batch your tool calls together for optimal performance. ALWAYS run the following bash commands in parallel, each using the Bash tool:
   - Run a git status command to see all untracked files.
   - Run a git diff command to see both staged and unstaged changes that will be committed.
   - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.
2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:
   - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.).
   - Check for any sensitive information that shouldn't be committed
   - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"

As you can see, Claude Code's system prompt contains hardcoded Git configuration to commit changes. Since system instructions override user prompts when you mention committing or version control, it defaults to Git commands even in Jujutsu repositories. Or at least this i how I interpret Claude Code's behaviour.

If the CLAUDE.md approach above doesn't work consistently, here are more advanced alternatives:

Advanced Solution: Custom Output Style

Output styles let you override Claude Code's system prompt entirely, giving you complete control over its behaviour. Here is my own summary of Claude Code output styles if you want to know more about this feature.

Setup steps:

  1. Start claude and run /output-style:new

  2. Name your style (e.g., jj-support) and complete the wizard

  • The initial content you enter doesn't matter since we'll replace it entirely in the next step

  1. Find the created .md file in .claude/output-styles/ (project or home) directory

  2. Replace its contents with a modified system prompt that includes Jujutsu support

You can use my pre-built version based on Claude Code 1.0.85's system prompt. These are the directives I added to add 'jj' support.

The critical addition is automatic repository type detection:

### MANDATORY FIRST STEP FOR ALL COMMITS

Before ANY commit-related commands, you MUST:
1. Run `bash: if jj root >/dev/null 2>&1; then echo "jj"; elif git rev-parse --git-dir >/dev/null 2>&1; then echo "git"; else echo "none"; fi`
2. If output is "jj" → use jj commands
3. If output is "git" → use git commands
4. If output is "none" → not a repository, inform user

NEVER use git commands if .jj directory exists, regardless of environment info.

NOTE: Environment "git repo" status may be misleading when both .jj and .git exist. Always use directory detection as the authoritative source.

(Turns out you can add logic inside a system prompt.)

Trade-offs:

  • ✅ Most reliable solution

  • ✅ Works even when CLAUDE.md is ignored or 'forgotten'

  • ❌ Requires maintenance when Claude Code updates, that is if you want to keep in sync with the latest default system prompt

  • ❌ Claude Code will request permission to run the detection command

Select your custom output style with /output-style and test by asking Claude to "commit the changes".

Experimental Solution: Command-Line Flag

The --append-system-prompt flag adds system instructions directly after Claude Code's system prompt at startup.

claude-code --append-system-prompt "In jj repositories, use jj commands instead of git commands."

Note: Simple instructions like the example above don't work. You'd need to pass the same comprehensive instructions used in the output style approach. I did not try this myself yet as for now I am done shaving this yak for now. I am sure you can pass the inputs from a file to the prompt making it more manageable as well.

Trade-offs:

  • ✅ No file modifications needed

  • ✅ Easy to test different configurations

  • ✅ Works at system level like hardcoded instructions

  • ❌ Must be added each time you start Claude Code (needs helper command)

Choosing the Right Approach

Start with CLAUDE.md configuration. It's simple, requires no system modifications, and should work for most users.

Upgrade to custom output style if:

  • Claude Code frequently ignores your CLAUDE.md instructions

  • You work with multiple Jujutsu repositories

  • You want the most reliable solution

  • You are willing to update the output style to the latest system prompts when it changes (significantly), or accept running with an outdated configuration version.

Consider the command-line flag for:

  • When you want to stay up to date with the latest system context versions without having to update the output style each time.

  • Testing different configurations quickly

Important Considerations

Missing Git Features

When you override Claude Code's Git behaviour, you lose may some built-in safety features:

  • Automatic sensitive information checking

  • Commit message formatting guidelines

  • Built-in branching workflow guidance

Consider adding these to your CLAUDE.md configuration if they're important to your workflow.

Bonus: No More Claude Branding in commit messages

A pleasant side effect is that Claude Code stops adding its promotional footer to commit messages:

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

Summary

To integrate Jujutsu workflows in Claude Code, but these three solutions exist:

  1. CLAUDE.md configuration: Simple and effective for most users

  2. Custom output styles: Most reliable but requires maintenance

  3. Command-line flags: Less maintenance and best for testing

Start with the CLAUDE.md approach. If Claude Code continues defaulting to Git commands despite your configuration, escalate to a custom output style for complete system-level control.

Thank you for reading, Hans