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

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

• Local environment cleanup script does not run after archiving Codex-managed worktree #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.
• MCP servers eat up memory when multi-tasking in Codex App #11324 and Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #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.
• Codex Desktop (Windows): UI-archived conversations reappear in active sidebar after refresh, and archive triggers flashing terminal cleanup #25541 and Codex Desktop Windows: archiving the active thread succeeds, then UI repeatedly resumes archived thread and freezes #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.