Codex App worktree creation resets dirty source checkout without confirmation or recovery snapshot

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

26.721.41059 (build 5848). Session metadata reports codex-cli 0.145.0-alpha.27.

What subscription do you have?

Unknown (signed-in Codex App account)

What platform is your computer?

Darwin 25.0.0 arm64 arm

What issue are you seeing?

Starting a Codex task in a managed worktree from a repository with a dirty primary checkout silently reset the primary checkout to HEAD.

Before worktree creation, the primary checkout contained:

• 16 modified tracked files
• 19 untracked files

After worktree creation:

• the new Codex task worktree contained the modified and untracked files;
• the original primary checkout was clean at HEAD;
• the primary worktree reflog contained reset: moving to HEAD at the worktree-creation timestamp;
• no Git stash or WIP commit was created;
• no explicit confirmation or recovery location was shown.

The files were eventually recovered from the task worktree and task history, but the behavior looked like destructive data loss. If the task worktree had been removed before recovery, unstaged and untracked content might not have been recoverable from Git reflog.

This was not a model-issued git reset. The reset occurred during Codex worktree initialization, before the first agent command.

What steps can reproduce the bug?

Observed sequence:

1. Open a Git repository in Codex App with the primary checkout on its default branch.
2. Modify multiple tracked files and create multiple untracked files. Do not commit or stash them.
3. Start a Codex task using a new managed worktree.
4. Inspect both worktrees with git status --short --untracked-files=all.
5. Inspect the primary checkout reflog with git reflog show --all --date=iso.

Observed result:

<timestamp> main-worktree/HEAD: reset: moving to HEAD
<timestamp> task branch: Created from HEAD
<timestamp> task worktree: checkout to codex/<task-branch>

The task worktree received the dirty state, while the primary checkout was rewritten to a clean HEAD. No corresponding stash existed.

I have not repeated this in a disposable repository because doing so risks another destructive source reset. Repository names, local paths, account identifiers, and file contents are intentionally omitted.

What is the expected behavior?

Codex App must not mutate or clean a dirty source checkout merely to create a managed worktree.

Safe options include:

1. Refuse worktree creation until the source checkout is clean.
2. Ask for explicit confirmation and explain whether changes will be copied or moved.
3. Create a durable recovery snapshot that includes untracked files before any reset.
4. Keep the primary checkout untouched and copy the diff into the new worktree.

If setup cannot prove that all tracked and untracked content has been preserved, it should stop before modifying either worktree.

Additional information

Relevant filesystem evidence:

• primary Git index timestamp changed immediately after the reflog reset;
• task worktree metadata was created immediately before that reset;
• initial task status matched the missing source inventory;
• there was no newly-created stash;
• exact recovery required reconstructing files later touched by the task.

Related but not duplicate: #33808 concerns applying a task diff onto a stale destination base. This report concerns Codex mutating and resetting the dirty source checkout during managed-worktree creation.

Suggested acceptance test:

1. Create a disposable repository with modified tracked files and untracked files.
2. Create a managed Codex worktree.
3. Assert byte-for-byte that the source checkout, source index, and source git status remain unchanged.
4. Assert that cancellation or failure at every setup stage leaves the source checkout unchanged.
5. If changes are transported, assert that a documented recovery artifact exists before any source mutation.