[Windows Desktop] Archiving a worktree thread appears to delete tracked files from the main checkout

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

• Version recorded by app logs at incident time: 26.707.72221
• Currently installed Windows package: 26.707.9981.0
• Codex CLI/runtime recorded in the affected session: 0.144.2

What subscription do you have?

ChatGPT subscription (exact tier omitted).

What platform is your computer?

• Windows 11 Home, version 10.0.26200, build 26200
• x64
• Native Codex Desktop for Windows

What issue are you seeing?

Archiving a Codex Desktop thread backed by a Codex-managed Git worktree appears to have triggered cleanup that removed tracked source files from the repository's main checkout, not only from the Codex worktree.

This is a suspected cross-path worktree cleanup bug. The evidence establishes a strong timing correlation, but I cannot prove the internal cleanup call because no corresponding filesystem-removal command was logged.

Impact

• The main checkout reported: 493 files changed, 1,075,278 deletions.
• The affected scope contained 498 tracked files; 493 were physically missing and only 5 remained.
• The missing files covered three frontend source roots.
• Tracked files are recoverable from Git, but the same behavior could irreversibly remove untracked or unstaged work.
• Git metadata and the rest of the repository remained intact.

Incident timeline (local time, UTC+8)

1. 08:05 — A request was made in an existing Codex-managed worktree to clean up a merged local branch.
2. The agent ran only Git/GitHub inspection and branch-maintenance commands under:

%USERPROFILE%\.codex\worktrees\<id>\<repo>

1. The recorded commands were limited to:

• git status
• PR status inspection
• git fetch origin master
• git switch master
• git merge --ff-only origin/master
• git branch -d <merged-branch>
• read-only verification

1. 08:07:14 — The task completed successfully.
2. 08:17:17 — Codex App logs recorded rpc.method="thread/archive" and shutdown of the main agent and its approval-review helper.
3. 08:18:10 and 08:18:53 — Empty affected directories in the main checkout received their last-write timestamps, consistent with their contents being removed immediately after thread archival.
4. The Codex-managed worktree directory was also gone after archival.
5. 08:55:53 — A later git switch master in the main checkout materialized exactly 5 files: the same 5 files that differed between the previously checked-out branch and master. The other 493 files remained missing because Git's index still considered them unchanged.
6. Git status then showed all 493 missing files as unstaged worktree deletions (.D in porcelain v2).

Checks performed

• Searched the complete affected Codex session tool-call log for rm -rf, Remove-Item, rmdir, shutil.rmtree, and other recursive deletion commands.
• No such model-issued command was present.
• No delayed/background deletion process was started by the agent.
• The agent's working directory was the Codex-managed worktree, not the main checkout.
• The main checkout was not sparse.
• No core.worktree override was configured.
• The 5 surviving tracked files matched the current master contents.
• The first git status run after the incident already contained the 493 deletions, before any later local or remote branch deletion commands were executed.

This points to Codex Desktop's thread archival/worktree cleanup path rather than an agent-generated shell deletion.

What steps can reproduce the bug?

I have not intentionally repeated the final archive operation because it risks another large data-loss event.

The incident sequence was:

1. On Windows, open a repository in Codex Desktop using a Codex-managed worktree.
2. Perform normal edits, commits, push, and PR work in that worktree.
3. After the PR is merged, ask Codex to fetch the default branch, switch the worktree to it, fast-forward it, and delete the merged local feature branch.
4. Wait for the task to finish.
5. Archive the Codex Desktop thread.
6. Inspect both the Codex-managed worktree path and the original/main repository checkout.
7. In this incident, the managed worktree was removed as expected, but hundreds of tracked files under the main checkout were also removed.

Potentially relevant repository characteristics:

• Native Windows Git repository outside %USERPROFILE%
• Codex-managed linked worktree under %USERPROFILE%\.codex\worktrees\
• workspace-write sandbox with on-request approval
• The repository contains tracked relative-link placeholder files because core.symlinks=false on Windows, but the affected roots themselves were ordinary directories

What is the expected behavior?

Archiving a Codex Desktop worktree thread must never modify the repository's original/main checkout.

Worktree cleanup should:

1. Resolve and canonicalize the cleanup target.
2. Verify that the final target is strictly inside the Codex-managed worktree root.
3. Refuse cleanup if any traversed directory, junction, symlink, mount, or resolved path escapes that root.
4. Remove only the registered Codex worktree and its own Git worktree metadata.
5. Preserve all files in the main checkout, including tracked, untracked, ignored, and unstaged files.
6. Log the resolved cleanup target and result so data-loss incidents can be audited.

Additional information

• Model used by the affected task: gpt-5.6-sol.
• This does not appear to be model-specific: the model-issued tool-call log contains no filesystem deletion command.
• The strongest correlation is between the Codex App thread/archive event at 08:17:17 and main-checkout directory removal beginning at 08:18:10.
• The report intentionally omits the Windows username, private repository name, remote URL, branch names, commit SHAs, source code, business data, and full Codex thread ID.
• Sanitized event rows or additional local diagnostics can be provided privately if maintainers need them.