Jujutsu support?

Question

Does anyone have experience using opencode with a Jujutsu repository? jj uses Git behind the scenes, so it's "compatible" with git - but my experiences are it doesn't always work well with coding agents.

If not, is there a way to use opencode without Git support (like I can with Claude Code)? By this I mean limiting Git usage to read only operations.

This issue relates to several existing discussions about OpenCode's Git dependency and version control support. Please check:

Why is OpenCode massively abusing git? #3176: "Why is OpenCode massively abusing git?" - Documents excessive git operations and potential for performance issues
Very slow session due to 98GB of git snapshots #3182: "Very slow session due to 98GB of git snapshots" - Related to git snapshot system without size limits
Session grew to 88G! #1126: "Session grew to 88G!" - Uncontrolled git snapshot storage growth
opencode automatically creating git commits and coauthoring itself #786: "opencode automatically creating git commits and coauthoring itself" - Shows automatic git operations without user control
[Feature Request] Allow for setting read-only files and directories. #1445: "[Feature Request] Allow for setting read-only files and directories" - Requests read-only mode similar to your ask
Not work in a git project, but normal work in a not git dir #2365: "Not work in a git project, but normal work in a not git dir" - Shows OpenCode has issues in git directories
OC fails with socket connection error when operating in a directory with a .git folder #2304: "OC fails with socket connection error when operating in a directory with a .git folder" - Indicates git folder dependency issues

These issues collectively suggest that OpenCode has a fundamental dependency on Git operations, including automatic snapshots and commits. Your feature request for Jujutsu support and read-only Git mode might benefit from the discussions in these threads, particularly regarding whether OpenCode can be designed to support alternative VCS systems.

I guess can you explain what you mean by without git support

and what your ideal situation is

Ideal: It understands the jujutsu version control (https://docs.jj-vcs.dev/latest/).

But what I can live with: A way to guarantee Opencode simply never modifies the git repository (no commit, no push, etc).

Right now I'm getting away with it because the default mode for jj is to put .git inside .jj, so git commands simply don't work unless you're in the .jj directory.

However, for projects where I'm working with others (who are using git), the .git directory is a sibling of .jj. If opencode then goes and modifies the git repo, it may make it harder to use jujutsu.

With Claude Code, I don't need to worry about it modifying the git repo. I'd like to have the same confidence in Opencode.

Have you seen our permissions system?
https://opencode.ai/docs/permissions/

You can block git commands

I use "ask" for some see this:

  "permission": {
    "bash": {
      "rm*": "ask",
      "git push*": "ask",
      "git checkout*": "ask",
      "git commit*": "ask",
      "git reset*": "ask",
    },
  },

So is git usage coming entirely from the LLM, and not something opencode has in it?

I've set all of "bash" to "ask", so I guess I've got this covered.

if you use git then opencode does do some git stuff internally but it doesnt change any of your files, we make a shadow git repo to try file changes and enable /revert but it won't or shouldnt mess with any of your stuff

I've been using JJ exclusively for the past 8-ish months with opencode, Claude (since 3.7), and Gemini (since 1.5) and have found the following things to be useful in directing the underlying LLMs to only use JJ commands. In general, they have gotten better as the models have progressed.

In my AGENTS.md file I have these lines

DO NOT make ANY git commands.
Use jj commands instead e.g., `jj describe -m "..."`, `jj log`, `jj status`, `jj diff` etc.

I also have some commands that are JJ specific, like creating a plan and then saving it to a markdown file before executing it.

---
description: Write a plan to a file and then complete it
temperature: 0.3
---

Ok. Write this plan to a file to provide checkpoints and reference back to it as you go
through the implementation. For each new step, use `jj new -m` to create a new blank jj
revision BEFORE starting the work, WITH a description of the work that will be done

or to add a revision description

---
description: JJ describe for the HEAD or the passed change ID
temperature: 0.3
---

You are working in a Jujutsu co-located repo.
You should provide comprehensive revision descriptions using `jj describe -m "..."`.
Provide a complete proposal for the revision: $ARGUMENTS and no other revisions.
You DO NOT need to check the jj log.
Then, check the changes in that revision using `jj show -r` on the revision specified.
Before making the change, ask for confirmation of the message.

DO NOT make ANY git commands. Use jj commands instead e.g., `jj describe -m "..."`, `jj log`, `jj status`, `jj diff` etc.
DO NOT run any code.

You could also create a tool plugin that intercepts bash invocations, detects if it's running a git command and then throw an error saying to user jj instead, that'd really force it

Working on a dedicated JJ plugin that may help! https://github.com/dpshade/jj-opencode

@arnold-c

@arnold-c how is jj in relations to this "Git Worktree" thing that some are talking about? Are they related in what they solve?

@TomLucidor

@TomLucidor I don't want to take us off on too much of a tangent to the issue here as that's not great for everyone who's involved in this issue and get notifications, but I will say that I just find JJ generally easier to work with than Git and all my projects use JJ now. I find jj undo and the oplog and evolog easier to work with than the reflog in git.

The main use of worktrees I've found is to avoid having to deal with stashes when you have to switch tasks and are maintaining a branch-per-feature approach to development (this post provides a decent overview of the motivations and use-case). However, I never really got along with that as I found that it is too much overhead for the work I typically do (managing stash or just placing a WIP commit that you amend isn't too hard), and the LSPs I typically use (90% Julia) don't do well with worktrees.

Steve Klabnik has an excellent online book/resource for JJ, and this page describes how you can achieve something that's a little similar to work on all branches simultaneously, but I haven't had a need to go that far - I can typically get away with just making edits in a single branch and using jj split -i (or jj squash -i, if working above an empty change to emulate the git staging area) to break things up as necessary. This is another good example of how you could replace worktrees with JJ, or, really, makes it easier to do feature branch approach if that's required (or just because you like that). This discussion in the JJ github is worth skimming to figure out what kind of workflow might work for you and your problems.

Anyway, to try and keep this issue on track for those that are working on it I think it's probably best to not continue this discussion further, but hopefully this is enough info to answer your questions and get you going in the right direction when it comes to looking into JJ.

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

Jujutsu support? #5008

Question

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Jujutsu support? #5008

Description

Question

Activity

github-actions commented on Dec 3, 2025

rekram1-node commented on Dec 3, 2025

rekram1-node commented on Dec 3, 2025

beetleb commented on Dec 3, 2025

rekram1-node commented on Dec 3, 2025

beetleb commented on Dec 3, 2025

rekram1-node commented on Dec 3, 2025

arnold-c commented on Dec 3, 2025

rekram1-node commented on Dec 3, 2025

dpshde commented on Dec 30, 2025

TomLucidor commented on Jan 20, 2026

arnold-c commented on Jan 26, 2026

github-actions commented on Mar 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions