Codex App fork or Continue-in-worktree applies source diff onto a stale default-branch commit

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.72221 (build 5307)

What subscription do you have?

Unknown (signed-in Codex App account)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Creating a worktree fork can select a stale local default-branch commit and then try to apply the source task's uncommitted working-tree diff onto that incompatible tree.

In the observed case:

• the repository's primary checkout was on the default branch but behind its remote;
• that primary checkout also had unrelated uncommitted files, so it could not safely be fast-forwarded;
• the source Codex task was in a detached worktree based on a different historical commit, with a substantial uncommitted diff;
• choosing Fork → new worktree prepared the fork at the stale primary-checkout commit rather than the source task's base/head or the current remote default branch;
• Codex then attempted to transplant the source diff. Files added or renamed after the stale commit were absent, while other files received conflicts;
• after git apply failed, the fallback path repeated partial direct-application attempts and emitted the same failures more than once. The new worktree was not usable.

Sanitized output shape:

Starting worktree creation
Preparing worktree (detached HEAD <stale-default-branch-sha>)
HEAD is now at <stale-default-branch-sha> <commit subject>
Applying working tree diff to new worktree
git apply failed: applied:3 skipped:7 conflicted:2
Falling back to direct application...
error: path/to/new-workflow.yml: does not exist in index
Applied patch to 'config-file' with conflicts.
error: path/to/renamed-test.nix: does not exist in index
Falling back to direct application...
...

The original repository and filenames are intentionally omitted. No repository content is needed to demonstrate the Git-state mismatch.

What steps can reproduce the bug?

1. Use a Git repository whose local primary checkout is on the default branch at commit A and is behind the remote default branch.
2. Leave unrelated uncommitted changes in that primary checkout, so silently moving it is not safe.
3. Have a Codex task in a detached worktree at a different commit B. Its working-tree diff should touch files that do not exist at A because they were added, renamed, or deleted between the two histories.
4. In the Codex App, fork that task and choose a new worktree.
5. Observe that worktree creation prepares detached A, then tries to apply the diff from B onto A.
6. Observe missing-index errors, partial conflicts, repeated fallback messages, and an unusable fork.

A second useful variant is to make the remote default branch current while leaving the local default branch stale. The fork still appears to derive its baseline from the stale local checkout.

What is the expected behavior?

A worktree fork should have an explicit, internally consistent base:

• Prefer the source task's exact Git base/head and then apply its uncommitted diff relative to that same base; or
• when the user requests a clean fork, create it from the selected ref (for example the current remote default branch) without importing the source diff.

If Codex cannot prove that the patch base matches the destination base, it should stop before modifying files and ask the user which state to use. It should not partially apply a patch, add conflict markers, and then repeat fallback attempts.

The dirty primary checkout must remain untouched.

Additional information

A successful workaround was:

1. Preserve the dirty primary checkout unchanged.
2. Manually create a separate clean worktree and branch directly from the current remote default branch.
3. Fork the Codex task in same-directory mode to avoid automatic patch transplantation.
4. Tell the child task to use the clean worktree path explicitly.

It would be useful for the fork dialog to offer these choices directly:

• Preserve source task state: exact source base/head plus its diff.
• Start clean from ref: select local branch, remote branch, tag, or SHA; do not carry a diff.

The setup log should also report the chosen source base, destination base, and patch base before attempting application.