Windows: archiving a managed worktree thread leaves node/node_repl processes locking the deleted directory

Start by tracing the managed worktree archive cleanup entry point on Windows, focusing on task-scoped node.exe and node_repl.exe shutdown and current-working-directory handling. Reproduce the issue with the listed steps, inspect git worktree list and child-process CWDs after archiving, and consider the work complete when the worktree root is deleted without live Codex children retaining it.

What version of the Codex App are you using?

Codex Desktop package 26.707.9981.0 (Windows app).

What platform is your computer?

Windows 11 x64.

What issue are you seeing?

Archiving a Codex-managed worktree thread successfully removes the Git worktree registration and the worktree contents, but one node.exe process and one node_repl.exe process remain alive with their current working directory set to the now-empty worktree root.

Because Windows does not allow deleting a directory that is the current working directory of a live process, the empty directory remains locked:

Remove-Item: The process cannot access the file
'%USERPROFILE%\.codex\worktrees\<id>\<repo>'
because it is being used by another process.

Terminating only those two remaining processes immediately releases the lock and allows the empty directory to be deleted.

Steps to reproduce

1. Open a Git repository in Codex Desktop on Windows.
2. Create a Codex-managed worktree task.
3. Interact with the task so its worker/tool runtimes are started.
4. Optionally create a temporary branch in the worktree. In this clean reproduction I used codex/test123; the worktree was otherwise clean.
5. From a separate task opened on the main checkout, ask Codex to archive the worktree-backed task. The app reports the archive as successful and the task disappears from the active task list.
6. Wait at least 25 seconds.
7. Inspect git worktree list, the target directory, and the current working directories of the remaining Codex child processes.

Reproduction thread ID: 019f6709-0cd0-70b3-839e-b58b1feb8d70

Observed result

The cleanup is only partial:

Additional checks:

• git worktree list showed only the main checkout after archive.
• Running Git in the old path failed with not a git repository, as expected after cleanup.
• The main checkout was unchanged.
• The temporary branch remained, which is normal Git behavior and is not part of this bug.
• The archived conversation was stored separately under the Codex archived-session storage; it was not stored in the worktree directory.
• This was reproduced cleanly after an earlier exploratory run.

Expected behavior

When a Codex-managed worktree task is archived:

1. All task-scoped runtimes should terminate or move their current working directory away from the worktree before removal.
2. The managed worktree root should be deleted completely, or deletion should complete after a short bounded grace period.
3. No live Codex child process should retain the removed checkout as its current working directory.

Related issues and why this appears distinct

• #19480 reports that the cleanup script does not run and the entire worktree remains Git-registered and on disk. Here, Git registration and contents are removed successfully; only the empty root is left because processes still hold it as their CWD.
• #11324 and #12491 report broader MCP/child-process accumulation, mainly on macOS. This reproduction is a deterministic Windows directory lock involving one node.exe and one node_repl.exe after a successful managed-worktree archive.
• #25541 and #25713 concern Windows archive UI/reconciliation behavior. This report is specifically about background archive cleanup and process/CWD lifetime.

The archive lifecycle appears to stop only one of each duplicated runtime pair, leaving the second node/node_repl pair attached to the deleted worktree path.