feat: git worktree isolation for write-capable rescue tasks #135

Problem

When /codex:rescue runs with --write, it uses Codex's native workspace-write sandbox, which edits files directly in the current working directory. This creates conflicts when:

1. Concurrent uncommitted work — The user has staged/unstaged changes in their working tree. Codex's edits interleave with the user's in-progress work, making it hard to separate what Codex changed from what the user was already doing.
2. Parallel Claude + Codex work — Claude Code may be actively editing files in the same directory while Codex rescue is running in the background. Both agents writing to the same files creates race conditions and merge conflicts.
3. Safe rollback — If Codex's changes are unwanted, the user has to manually git checkout individual files or use git stash tricks. With a worktree, you just git worktree remove and it's gone.

Proposed Solution

For write-capable rescue tasks, optionally create a git worktree so Codex operates in an isolated copy of the repository:

git worktree add .worktrees/codex-<timestamp> -b codex/<timestamp>

Then run the Codex task against the worktree path instead of the main working directory. After completion:

• Keep: Generate a patch from the worktree and apply it to the main tree, or let the user merge the branch
• Discard: git worktree remove + git branch -D

This could be exposed as a --worktree flag on /codex:rescue, or made the default for background write tasks where the risk of conflict is highest.

Prior Art

I built a custom Codex skill for Claude Code that uses this exact pattern — subagent creates a worktree, runs codex exec -s workspace-write inside it, then presents a diff for review before applying. It works well in practice and eliminates the concurrent-edit problem entirely.

Alternatives Considered

• Stash-based isolation: git stash before Codex runs, restore after. Fragile and loses staged vs unstaged distinction.
• Branch-based: Just create a branch. Doesn't help — still editing the same working directory.
• Do nothing: Users accept the risk. Works for simple cases but breaks down with background tasks or concurrent editing.