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

Open 💬 2 comments Opened Apr 25, 2026 by 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.
  1. 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
  1. 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
  1. Start a new Codex thread using a Codex-managed worktree and this local environment.
  1. Confirm the setup script ran successfully.
  1. Archive the associated Codex thread from the Codex Desktop UI.
  1. 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:

  1. 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.

View original on GitHub ↗

2 Comments

dvic · 3 months ago

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

tonydehnke · 9 days ago

I reproduced the same outcome on macOS with a newer build.

  • Codex Desktop: 26.814.41407 (build 6720)
  • Bundled CLI: codex-cli 0.148.0-alpha.15
  • macOS: 27.0 (26A5416b), arm64
  • Automatic worktree cleanup enabled; keep-count 7
  • Affected task: 01a01718-b976-7df3-b478-45300ef3bbfc

In 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.

  • The managed-worktree task was idle when archived (had_active_turn=false).
  • thread/archive succeeded at 2026-08-19T00:20:46Z, and task state recorded the archive timestamp.
  • The Archive RPC identified its client as codex_chatgpt_ios_remote 1.2026.223.
  • No refs/codex/snapshots/... ref was created for the worktree HEAD.
  • Desktop logs contain no worktree-snapshot, worktree-delete, archive-cleanup, or cleanup-script invocation for this archive.
  • At a repeated check about 39 minutes later, the worktree was still Git-registered and present on disk, and both exact per-worktree databases remained.
  • The scoped ports, processes, and network routing were already clear.

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 7 should 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.