[desktop] Uncommitted changes are silently overwritten when multiple sessions share the same worktree

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

26.803.61601 (build 6396)

What subscription do you have?

plus

What platform is your computer?

macOS 26.5.2, Darwin 25.5.0, arm64

What issue are you seeing?

When two Codex App sessions use the same Codex-managed Git worktree, uncommitted changes made by one session can be silently overwritten when another session synchronizes or switches to that worktree.

No warning or error is shown. The removed changes disappear from the live working tree and are not listed by git stash list. They can only be recovered through low-level Git object inspection.

I reproduced this twice. In the latest reproduction, the lost content remained only as an unreachable Git blob:

89ae5b1bcaf3846924e33c0c262db0c18a7e2c5d

The blob was contained in an unreachable temporary stash commit:

4fcee9ceb29defdd2b08aa9e4dc09937497ab29f

Commit subject:

On (no branch): Stashed Codex worktree changes

This is effectively user-data loss because unreachable Git objects may later be removed by garbage collection.

Expected behavior: Codex should prevent concurrent ownership of one worktree, preserve dirty changes under a durable reference, or show a conflict instead of silently overwriting them.

What steps can reproduce the bug?

1. Open Session A with a Codex-managed Git worktree.
2. Modify a tracked file without staging or committing it.
3. Verify that git diff and git status show the modification.
4. Open or switch to Session B using the same repository and worktree.
5. Make another change or allow Session B to synchronize the worktree.
6. Return to Session A.
7. Inspect the original file and run git status and git stash list.

Observed result:

• Session A's uncommitted changes have disappeared.
• The file contains the state written or restored through Session B.
• No conflict or data-loss warning is shown.
• The original changes are absent from normal Git recovery paths.
• The worktree may also switch from detached HEAD to a named branch.

What is the expected behavior?

No response

Additional information

No response

No source file or test is named. Start by reproducing the shared-worktree scenario and tracing the desktop synchronization, stash, and branch-switching entry points; inspect how dirty changes are handled. Done means concurrent sessions no longer silently overwrite uncommitted changes, and changes are preserved or a clear conflict is reported.