Feature request: support Jujutsu (jj) as a VCS frontend, not just Git

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:

• #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.