Local environment cleanup script does not run after archiving Codex-managed worktree

[MohamedGharabawy]

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

26.422.30944 (build 2080)
Codex CLI: codex-cli 0.125.0

What subscription do you have?

ChatGPT Pro / Team / Enterprise

What platform is your computer?

Darwin 25.4.0 x86_64 i386

What issue are you seeing?

I am seeing a possible bug or unclear behavior with Codex Desktop local environment cleanup scripts.

I configured a Codex Desktop local environment with both setup and cleanup scripts. The setup script creates per-worktree resources, and the cleanup script is supposed to remove them.

After archiving the associated Codex-managed worktree thread, the cleanup script did not run. The worktree also remained on disk and was still listed by Git.

In my real case, the setup script created:

• a generated per-worktree test database
• a per-worktree port registry entry
• a generated ignored config file inside the worktree

After archiving the thread, I verified:

worktree path: <HOME>/.codex/worktrees/4a21/2270-YoDa
dir_exists=yes
git_worktree_listed=yes
generated_test_db_exists=yes
port_registry_entry_still_exists=yes

What steps can reproduce the bug?

Uploaded thread: 019dbff7-c97d-7511-9af5-1cee07dd1ab2

Steps:

1. Create a Codex Desktop local environment for a repo.

2. Add a setup script that creates per-worktree resources. In my case, the setup script:

   • generated config/application.yml inside the worktree
   • assigned a per-worktree Rails port
   • created a per-worktree test database
   • wrote the assigned port to a local registry file

3. Add a cleanup script that removes those resources. In my case, the cleanup script:

   • removes the worktree entry from the port registry
   • drops the generated per-worktree test database

4. Start a new Codex thread using a Codex-managed worktree and this local environment.

5. Confirm the setup script ran successfully.

6. Archive the associated Codex thread from the Codex Desktop UI.

7. Check whether the cleanup script ran.

Actual result after archive:

worktree path: <HOME>/.codex/worktrees/4a21/2270-YoDa
dir_exists=yes
git_worktree_listed=yes
generated_test_db_exists=yes
port_registry_entry_still_exists=yes

The thread was archived, but the worktree remained and the cleanup script did not run.

What is the expected behavior?

When a Codex-managed worktree thread is archived, I expected Codex to either:

1. Delete the associated worktree and run the configured local environment cleanup script.

Or:

2. Clearly indicate that cleanup is delayed and explain when the cleanup script will actually run.

The current behavior is confusing because the Worktrees docs say Codex-managed worktrees are deleted automatically when the associated thread is archived, but in this case the worktree and generated resources remained.

Expected cleanup result:

• worktree deleted or marked clearly as pending deletion
• cleanup script executed
• generated test database removed
• port registry entry removed

Additional information

I searched existing issues and did not find an exact duplicate for local environment cleanup scripts not running after archiving a Codex-managed worktree.

Potentially related lifecycle/cleanup issues:

• Codex Desktop on macOS: worktree creation can time out after Git succeeds, leaving orphaned worktrees with no thread/session state #16936: worktree creation can time out after Git succeeds, leaving orphaned worktrees with no Codex thread/session state.
• Desktop app leaves stale temp worktree and blocks switching back to main #14575: stale temp worktree blocks branch switching.
• Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491: Codex.app does not reap child processes after task completion and discusses worktree lifecycle cleanup.
• MCP servers eat up memory when multi-tasking in Codex App #11324: closing/archiving conversations may leave stale MCP/conversation processes.
• Codex desktop is showing stale/orphaned thread entries that cannot be reopened or archived. #14162: stale/orphaned thread entries cannot be reopened or archived.

This issue seems distinct because it is specifically about the expected behavior of the configured local environment cleanup script when the associated Codex-managed worktree thread is archived.

[dvic]

have you tried removing the cleanup script, in our case the script itself threw a error causing this error ^^