›_ Codex Issues
Codex Issues / #16004

Curated plugin startup sync leaks ~/.codex/.tmp/plugins-clone-* directories on failure

Open 💬 6 comments Opened Mar 27, 2026 by Alek2077
💡 Likely answer: A maintainer (xl-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

Plus

Which model were you using?

Not model-specific. This appears to happen during curated plugin startup sync before normal task work.

What platform is your computer?

Linux x86_64

What issue are you seeing?

The new curated plugin startup sync can leave behind leaked temp repositories under:

$HOME/.codex/.tmp/plugins-clone-*

After upgrading to 0.117.0, I started seeing multiple extra git repositories in VS Code source control. These were not part of my workspace repo. They turned out to be temp clones under ~/.codex/.tmp/, some partially cloned, some empty, some full git repos with thousands of staged deletions/untracked files.

Local evidence from ~/.codex/log/codex-tui.log:

  • 2026-03-27T09:00:22.665896Z WARN codex_core::plugins::startup_sync: git sync failed for curated plugin sync; falling back to GitHub HTTP error=git clone curated plugins repo timed out after 30s: Cloning into '/home/.../.codex/.tmp/plugins-clone-LtJPVl'... fatal: early EOF
  • 2026-03-27T12:43:09.973193Z WARN codex_core::plugins::startup_sync: git sync failed for curated plugin sync; falling back to GitHub HTTP error=git clone curated plugins repo timed out after 30s: Cloning into '/home/.../.codex/.tmp/plugins-clone-k0He1F'... fatal: early EOF
  • 2026-03-27T12:43:41.545229Z WARN codex_core::plugins::manager: failed to sync curated plugins repo: failed to read download curated plugins archive response from https://api.github.com/repos/openai/plugins/zipball/aef533fd6ce0acf9b4850a5de33328a30731c18a: error decoding response body

On disk afterward I had a mix of leftovers:

  • full repos with .git, README.md, .gitignore, .agents, plugins
  • partial repos with only .git
  • empty plain dirs

Example leftover paths:

  • $HOME/.codex/.tmp/plugins-clone-EVIX7x
  • $HOME/.codex/.tmp/plugins-clone-JyUIh3
  • $HOME/.codex/.tmp/plugins-clone-KHGHUg
  • $HOME/.codex/.tmp/plugins-clone-LtJPVl
  • $HOME/.codex/.tmp/plugins-clone-k0He1F

Some of the full leftovers resolved to the curated plugins repo:

  • origin = https://github.com/openai/plugins.git
  • HEAD = aef533fd6ce0acf9b4850a5de33328a30731c18a

What steps can reproduce the bug?

I do not yet have a deterministic minimal repro, but the observed failure pattern is:

  1. Run Codex CLI 0.117.0
  2. Curated plugin startup sync attempts to refresh the local curated marketplace under ~/.codex/.tmp/plugins
  3. The git path times out or fails partway through (early EOF)
  4. The HTTP fallback also fails or does not complete cleanup
  5. One or more plugins-clone-* temp dirs remain permanently under ~/.codex/.tmp/

This is likely easier to reproduce by forcing network instability or a timeout during:

  • git clone https://github.com/openai/plugins.git
  • or the fallback zipball download from GitHub API

What is the expected behavior?

Failed curated plugin sync attempts should not leave leaked temp dirs or temp git repos behind.

Expected behavior:

  • temp clone/extract dirs are cleaned up on every error path
  • only the final active curated marketplace path remains:
  • ~/.codex/.tmp/plugins
  • VS Code or other git-aware tools should never see plugins-clone-* leftovers as standalone repos

Additional information

I think the root cause is visible in source.

In codex-rs/core/src/plugins/startup_sync.rs, prepare_curated_repo_parent_and_temp_dir() creates a temp dir and immediately calls:

  • tempfile::Builder::new().prefix("plugins-clone-").tempdir_in(parent)?
  • then clone_dir.keep()

That means the temp dir is detached from tempfile auto-cleanup before clone/download/activation has succeeded.

Then both sync paths use that kept directory:

  • sync_openai_plugins_repo_via_git()
  • sync_openai_plugins_repo_via_http()

There does not appear to be cleanup if any later step fails, for example:

  • git clone timeout / early EOF
  • zipball download failure
  • zip extraction failure
  • marketplace manifest validation failure
  • activation failure

So the likely bug is:

prepare_curated_repo_parent_and_temp_dir() promotes the temp dir to a persistent path too early, and failure paths never remove it.

That matches the exact symptom on disk:

  • partial clone directories remain after failed git clone
  • empty directories remain after failed fallback stages
  • full repos can remain if later activation/validation does not complete

If helpful, I can provide the exact local log lines and leftover directory shapes again, but the source path above already seems to explain the leak.

View original on GitHub ↗

6 Comments

Boulea7 · 3 months ago

I took a closer look at the current Rust implementation, and the report seems directionally correct.

Both sync paths in codex-rs/core/src/plugins/startup_sync.rs stage into a temporary curated repo directory before activation:

  • sync_openai_plugins_repo_via_git()
  • sync_openai_plugins_repo_via_http()

The important bit is that prepare_curated_repo_parent_and_temp_dir() creates that temp dir and immediately calls keep(), so the staged directory stops being self-cleaning before the sync has actually succeeded.

From there, any error before activate_curated_repo(...) can leave the staged path behind, including:

  • git clone timeout / early EOF
  • zipball download or response-body failure
  • zip extraction failure
  • missing marketplace manifest
  • activation failure after staging is already populated

So the leaked ~/.codex/.tmp/plugins-clone-* directories described here are consistent with the current lifecycle.

The smallest fix shape still looks like:

  • keep the staged directory under TempDir ownership for the entire staging/sync flow
  • only persist it by renaming it into the final curated repo location once activation succeeds

Doing explicit cleanup on every failure branch would also work, but keeping the staged directory owned by TempDir until success seems less error-prone.

I also checked the existing startup_sync_tests.rs coverage. Right now it already exercises the happy path and git->HTTP fallback behavior, but it does not appear to assert cleanup of leftover plugins-clone-* directories on failure. A focused regression here would probably be:

  • one git failure case that asserts no staged clone dirs remain afterward
  • one HTTP-side failure case (download / extract / manifest validation) with the same cleanup assertion

I have not reproduced this live end-to-end locally, so this is based on source inspection rather than a full runtime repro, but from the code as it stands this does look like a real staged-directory lifecycle bug.

xl-openai contributor · 3 months ago

Thanks for reporting! A fix should be merged and will release soon.

Bryan2333 · 3 months ago

I want to clarify an additional issue on Windows 11.

In my case, the leaked plugins-clone-* directories are not only left behind, but are sometimes created in the root of the C: drive instead of under CODEX_HOME.

I have:
CODEX_HOME=C:\Users\Bryan\.config\codex

However, I found directories like:
C:\UsersBryan.configcodex.tmpplugins-clone-DWfzYn

Notice this is incorrectly placed in C:\ and the path separators are missing.

From Git Bash, the working directory appears as:
/c/?C:UsersBryan.configcodex.tmpplugins-clone-DWfzYn

This suggests a path normalization issue when handling Windows paths (likely mixing Windows-style paths with POSIX paths incorrectly).

These directories are valid git repos with:
origin = https://github.com/openai/plugins.git

So in addition to the temp directory leak, there may also be a Windows-specific path handling bug causing incorrect directory placement.

<img width="819" height="429" alt="Image" src="https://github.com/user-attachments/assets/e9c0d239-4716-41ac-b7f7-5021b15ec50d" />

Alek2077 · 2 months ago

This still appears to happen on codex-cli 0.128.0.

Fresh local evidence from May 1, 2026:

  • leftover path: $HOME/.codex/.tmp/plugins-clone-X6PMR0
  • remote: https://github.com/openai/plugins.git
  • HEAD: 3c46336323290cda7c90d78e7a0134f47cc73713
  • active $HOME/.codex/.tmp/plugins existed separately and was clean at the same HEAD
  • the leaked clone had no .git/index, so Git reported the repo as thousands of staged deletions plus untracked files

I removed the leaked temp clone manually, and the source-control noise disappeared.

Bryan2333 · 2 months ago

I'm currently using codex-cli v0.128.0. I've noticed that after launching it multiple times, temporary plugin directory is no longer being created in C:\.

il-alexk · 1 month ago

Confirmed this still exists in codex-cli 0.139.0.

On WSL2, repeated codex exec runs create and leave behind new:

$CODEX_HOME/.tmp/plugins-clone-*

directories. In a fresh CODEX_HOME, each successful trivial run like
codex exec "Say Hi" added another plugins-clone-* dir.

Workaround:

[features]
plugins = false

or per command:

codex exec --disable plugins "Say Hi"

As extra cleanup insurance:

rm -rf "$CODEX_HOME"/.tmp/plugins-clone-*