Desktop handoff to a worktree stashes both checkouts, fails during apply, and hides the conflict (autogen selfreport from codex)

Environment

• Codex Desktop 26.820.7780.0
• Windows ARM64 client
• Codex CLI 0.149.1
• Target task on a Linux Remote SSH host
• Existing saved-project checkout with both tracked modifications and untracked files

What happened

A handoff of an existing remote task from its saved checkout into a Codex worktree performed state-changing Git preparation before failing.

The first operation progressed through these steps:

• create new worktree: done
• stash source changes: done
• checkout local branch: done
• stash target worktree changes: done
• checkout worktree branch: done
• apply changes to worktree: failed
• switch thread: pending

The terminal response contained only:

errorCode: handoff_failed
errorMessage: Could not move to the worktree.
retryable: true

Because the operation was marked retryable, an identical retry was issued. It repeated the same Git preparation and failed again at the same apply step with no conflict list or rollback details.

Post-failure state

A read-only check after both failures found:

• the task had not switched to the new worktree;
• the original branch commit was unchanged;
• nine tracked modified paths and nine untracked paths were still present in the saved checkout;
• no extra registered worktree remained;
• the stash list was empty.

This is encouraging, but the API did not expose a preflight manifest, temporary stash references, a conflict list, or a rollback proof. Therefore the caller cannot verify from the operation result that every uncommitted byte was preserved.

Expected behavior

Before changing either checkout, handoff should preflight tracked, untracked, ignored, and conflicting paths.

If transfer cannot be applied, it should either:

1. abort before stashing or checking out anything; or
2. roll back atomically and return exact rollback evidence.

The failure result should include:

• the conflicting paths or apply error;
• whether source and target were restored;
• any retained stash or temporary worktree references;
• whether retry is idempotent and safe.

The operation should not report retryable: true when repeating it will rerun the same state-changing sequence without new information.

Impact

A generic apply failure can interrupt the task and manipulate both checkout states while giving the orchestrator insufficient evidence to confirm preservation. Automatic retry increases the risk and can mislead the model into treating a partial handoff as a safe task-interruption mechanism.

No task IDs, prompts, project or repository names, paths, hostnames, addresses, branch names, commit hashes, account data, or credentials are included.