Local environment cleanup script does not run after archiving Codex-managed worktree
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:
- Create a Codex Desktop local environment for a repo.
- Add a setup script that creates per-worktree resources. In my case, the setup script:
- generated
config/application.ymlinside the worktree - assigned a per-worktree Rails port
- created a per-worktree test database
- wrote the assigned port to a local registry file
- 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
- Start a new Codex thread using a Codex-managed worktree and this local environment.
- Confirm the setup script ran successfully.
- Archive the associated Codex thread from the Codex Desktop UI.
- 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:
- Delete the associated worktree and run the configured local environment cleanup script.
Or:
- 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:
- #16936: worktree creation can time out after Git succeeds, leaving orphaned worktrees with no Codex thread/session state.
- #14575: stale temp worktree blocks branch switching.
- #12491: Codex.app does not reap child processes after task completion and discusses worktree lifecycle cleanup.
- #11324: closing/archiving conversations may leave stale MCP/conversation processes.
- #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.
2 Comments
have you tried removing the cleanup script, in our case the script itself threw a error causing this error ^^
I reproduced the same outcome on macOS with a newer build.
26.814.41407(build6720)codex-cli 0.148.0-alpha.1527.0(26A5416b), arm64701a01718-b976-7df3-b478-45300ef3bbfcIn this occurrence, Archive was initiated by a Remote Control client while Codex Desktop was open and connected on the host throughout. The same Desktop app-server process was running before the RPC and continued logging afterward.
had_active_turn=false).thread/archivesucceeded at2026-08-19T00:20:46Z, and task state recorded the archive timestamp.codex_chatgpt_ios_remote1.2026.223.refs/codex/snapshots/...ref was created for the worktree HEAD.worktree-snapshot,worktree-delete,archive-cleanup, or cleanup-script invocation for this archive.This rules out the configured cleanup script throwing in this occurrence: the app never invoked it.
For contrast, earlier the same day on the same host, app build, and configuration, archiving a different managed-worktree task from Codex Desktop itself did create the snapshot and dispatch the cleanup script. That cleanup then stopped on an unrelated local Tailscale missing-handler response, but the snapshot and dispatch both happened. This is not yet a controlled A/B, but it is evidence that the skipped dispatch may be specific to remote-initiated archives—possibly related to #32940, where Remote Control archive state does not reconcile with Desktop as expected.
The Worktree cleanup documentation says a managed worktree is snapshot-and-deleted when its associated chat is archived, without distinguishing by client. It lists archiving and count-based retention as separate deletion triggers, so the configured keep-count of
7should not suppress Archive cleanup.I have not yet run a controlled fresh-task Desktop-vs-Remote comparison. I’m happy to provide the sanitized event timeline or additional logs if useful.