Codex app: support Jujutsu (`jj`) workspaces or custom worktree backend

What variant of Codex are you using?

App

What feature would you like to see?

Please add support for Jujutsu (jj) workspaces in Codex App worktree flows, or expose a custom worktree-create/worktree-remove hook so users can replace Codex's default git worktree behavior.

Today, Codex App worktrees are Git worktrees. That works well for Git repos, but it is a poor fit for users running a colocated Jujutsu/Git repo. Jujutsu does not support Git worktrees as its native multi-checkout primitive; its equivalent is jj workspace. If Codex creates a Git worktree from a colocated jj repo, that checkout can be usable as files/Git, but it is disconnected from the user's jj workspace graph and normal jj log / jj rebase / jj squash workflow.

The requested behavior could be either:

1. Native detection/support for jj repos and jj workspace add / jj workspace forget in Codex App worktree flows.
2. A project-level hook/config mechanism for worktree creation/removal, where Codex passes the requested worktree name/base context and consumes the absolute path returned by the hook.

The second option may be more general and would also help users with non-standard worktree locations or other VCS/workspace managers.

Why this matters

Jujutsu is increasingly common in AI-agent workflows because its change graph and automatic rebasing make stacked or parallel changes easier to manage. The current Codex App model creates Git worktrees under $CODEX_HOME/worktrees, but for jj users the desired isolated working directory is a jj workspace, not a Git worktree.

The gap shows up in this personal workflow:

• I want to use jj locally for parallel agent work and stacked PR preparation.
• I want Codex App threads/worktree handoff/local environments to keep working.
• If Codex creates Git worktrees, those worktrees do not participate cleanly in the jj workspace graph.
• If I manually create jj workspace directories, I can open them as local projects, but Codex's native Worktree/Handoff/Local Environment flow is not integrated with that model.

Possible design

A hook/config API similar to:

• WorktreeCreate: input includes project root, requested name, base branch/revision/commit, and whether local uncommitted state should be copied/applied. Output is the absolute workspace path Codex should use.
• WorktreeRemove: input includes the absolute path returned earlier; hook performs cleanup/archive/forget.

For jj, a user script could run something like:

jj workspace add "$TARGET_DIR" -r "$BASE_REVISION"
echo "$TARGET_DIR"

and cleanup could run:

cd "$TARGET_DIR" && jj workspace forget

Additional information

Related context:

• jj docs list git-worktree as unsupported and point users to jj workspace instead.
• Claude Code recently added a WorktreeCreate hook that replaces default Git worktree behavior; that shape seems like a pragmatic model for Codex too.
• This is separate from broader worktree UI issues like configurable worktree directories or multiple threads per worktree. Those would still be useful, but they do not address the jj workspace backend mismatch.