Feature request: support Jujutsu (jj) as a VCS frontend, not just Git · Issue #31167 · openai/codex · GitHub
//voltron/issues_fragments/issue_layout" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//voltron/issues_fragments/issue_layout;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
Uh oh!
There was an error while loading. Please reload this page.
openai
codex
Public
Notifications<br>You must be signed in to change notification settings
Fork<br>14.2k
Star<br>95.6k
Feature request: support Jujutsu (jj) as a VCS frontend, not just Git #31167
New issue<br>Copy link
New issue<br>Copy link
Open
Open<br>Feature request: support Jujutsu (jj) as a VCS frontend, not just Git#31167
Copy link
Labels<br>enhancementNew feature or requestNew feature or request
Description
exlee<br>opened on Jul 5, 2026
Issue body actions
Summary
There is already a related issue for workspace/worktree support: Codex app: support Jujutsu (jj) workspaces or custom worktree backend #26648.
This feature request is broader. I would like Codex to support Jujutsu (jj) as a first-class VCS frontend overall, not only as a workspace or worktree backend.
Problem
Many developers and teams use jj on top of Git repositories, but Codex currently seems to rely on Git-only assumptions for common version-control operations.
Issue #26648 covers an important part of the problem for the Codex app: workspaces/worktrees. But the broader gap is that jj users need Codex to understand Jujutsu workflows more generally, not just how to create isolated working directories.
This creates friction in workflows where jj is the primary interface for:
status inspection
change/revision management
diff generation
creating or describing changes
navigating history
revert/restore flows
bookmark- or branch-aware operations
Requested behavior
Please add an option for Codex to support Jujutsu as a first-class VCS frontend.
Possible approaches:
auto-detect jj when available in a repo and prefer it when configured
provide an explicit setting to choose git vs jj
support a hybrid mode where Codex understands a jj workflow while still interoperating with Git remotes
Relationship to #26648
I want to explicitly acknowledge that #26648 already exists and covers workspace/worktree integration.
This request is different in scope:
Codex app: support Jujutsu (jj) workspaces or custom worktree backend #26648 is about Codex app workspaces or custom worktree backends
this issue is about broader end-to-end Jujutsu support across Codex's version-control behavior
In other words, even if Codex gained jj workspace support for the app, there would still be value in broader support for jj commands and workflows throughout the product.
Minimum useful support
At a minimum, it would be helpful if Codex could handle jj equivalents for:
repository status
diff/review context
change creation / revision workflows
commit or description updates
revert / restore flows
bookmark-aware operations where relevant
Why this matters
jj is growing in adoption because it offers a more flexible workflow on top of Git-compatible repositories. Supporting it would make Codex much more usable for people who already rely on jj day to day.
Notes
I’m not asking Codex to abandon Git behavior. I’m asking for jj to be supported as an option for users and repos that prefer it.
Reactions are currently unavailable
Metadata<br>Metadata<br>Assignees
No one assigned
Labels
enhancementNew feature or requestNew feature or request
Type
No type
Fields
No fields configured for issues without a type.
Projects
No projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions<br>Open in GitHub Copilot app
You can’t perform that action at this time.