Plugin install fails with EBUSY on Windows for PRIVATE repos (public works fine; not casing-related)

TL;DR

On Windows 11 / Claude Code v2.1.143, /plugin marketplace add <owner>/<repo> reliably fails during the post-clone rename step for private repos. Flipping the same repo to public (via gh repo edit --visibility public) — no other change — makes the install succeed cleanly. This means the underlying bug is private-repo-specific on Windows, not the case-sensitivity race that issue #23205 frames it as.

Existing issues #23205, #36823, #17201, #26834 are related but don't capture the private-vs-public distinction empirically.

Repro (verified back-to-back, same machine, same Claude Code session)

Step 1 — Lowercase org, private repo (FAILS)

Created lens-co/marketplace-smoke-test (fully lowercase org lens-co, minimal repo with .claude-plugin/marketplace.json + a no-op smoke plugin). Repo visibility: private.

/plugin marketplace add lens-co/marketplace-smoke-test

Error: Failed to finalize marketplace cache. Please manually delete the directory at
C:\Users\janho\.claude\plugins\marketplaces\marketplace-smoke-test if it exists and try again.

Technical details: EBUSY: resource busy or locked, rename
  'C:\Users\janho\.claude\plugins\marketplaces\lens-co-marketplace-smoke-test' ->
  'C:\Users\janho\.claude\plugins\marketplaces\marketplace-smoke-test'

Empty orphan dir lens-co-marketplace-smoke-test/ left behind (clone partially completed, cleanup wiped contents, dir residue remained, rename failed).

Step 2 — Flip visibility to public (PASSES)

gh repo edit lens-co/marketplace-smoke-test --visibility public --accept-visibility-change-consequences

Then retry the exact same install command from a clean Claude Code session:

/plugin marketplace add lens-co/marketplace-smoke-test
/plugin install smoke@marketplace-smoke-test

Both succeed. No EBUSY. No manual workaround needed.

Nothing else changed between the two runs. Same repo, same files, same git commit SHA, same machine, same Claude Code build. Only the repo visibility differed.

Why this matters

Existing diagnostic framing (#23205 "mixed-case org casing → cleanup race", closed as not-planned) directed users toward casing fixes that don't help. I created a lowercase lens-co org specifically to dodge #23205 — same failure.

The real-world impact for consultants / small teams distributing private customer-specific plugins to Windows users is significant: every install requires the manual clone + known_marketplaces.json edit workaround, which is hostile to non-developer end users.

Hypothesis on the underlying cause

I can't see the install code, but the symptom pattern (EBUSY: resource busy or locked during rename, with the source dir surviving but emptied) suggests a Windows file-handle race between the clone process's cleanup and the rename. Authenticated git clones for private repos may keep an additional handle open (credential manager, .git/HEAD.lock for the brief window when fetching refs) that public clones don't. Pure speculation; flagging in case it helps narrow down.

Workaround currently in use

Manual clone + registry edit:

git clone https://github.com/<owner>/<repo>.git "$env:USERPROFILE\.claude\plugins\marketplaces\<repo>"
# Then manually add an entry to ~/.claude/plugins/known_marketplaces.json:
#   "<repo>": {
#     "source": { "source": "github", "repo": "<owner>/<repo>" },
#     "installLocation": "...",
#     "lastUpdated": "..."
#   }
# Restart Claude Code or /reload-plugins.

Works but is not something we can ask end-users (Dockx staff in our case) to do.

Environment

• Claude Code: v2.1.143
• OS: Windows 11 Pro 10.0.26200
• GitHub auth: HTTPS via gh CLI, free GitHub account, no organization membership at fault (same failure under lens-co org as under personal account)
• File system: NTFS, OneDrive sync not present on ~/.claude/ path
• Antivirus: Windows Defender default (not modified for this test)
• 8 existing marketplaces install fine on the same machine — all of them are public repos. The only failing installs are the two private repos we tried (JuanSombrero23/dockx-data-agent and lens-co/marketplace-smoke-test).

Ask

Either:

1. Reframe #23205 / re-open with the private-repo distinction so future searchers find it correctly, OR
2. Document the private-repo-on-Windows install path officially (manual clone + registry as the supported workaround), OR
3. Fix the file-handle race in the install pipeline so private repos work too.

The current state (closed-as-not-planned with misleading framing) sends users in circles. Happy to provide more diagnostic info — Process Monitor traces, et al — if helpful.