[BUG] can not add marketplace on windows

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

yes its still occuring

yes, the issue still exists in the newest version

it's still occuring in claude code v2.1.23
but only when installing superpowers plugin in claude-plugins-official marketplace

Open PowerShell in C:\Users\<user>\.claude\plugins, run claude to enter the Claude interface, then perform the operation.

I'm getting a similar issue, but only in Cowork for some reason

/plugin marketplace add anthropics/skills ⎿ Error: Failed to finalize marketplace cache. Please manually delete the directory at C:\Users\.claude\plugins\marketplaces\anthropic-agent-skills if it exists and try again. Technical details: EPERM: operation not permitted, rename 'C:\Users\.claude\plugins\marketplaces\anthropics-skills' -> 'C:\Users\.claude\plugins\marketplaces\anthropic-agent-skills'

version2.1.62, This problem still exists.

2.1.68 (Claude Code) still exists

It still occurs (v2.1.70 ) when adding the superpowers marketing place.
#31433

Open PowerShell in C:\Users\<user>\.claude\plugins, run claude to enter the Claude interface, then perform the operation.

Yes, just need to trust the folder.

This issue still occurs on Windows 11 Pro (10.0.26200) with Claude Code latest version (April 2026).

Error: Failed to finalize marketplace cache. Please manually delete the directory at
C:\Users\<user>\.claude\plugins\marketplaces\omc if it exists and try again.

Technical details: EPERM: operation not permitted, rename
'C:\Users\<user>\.claude\plugins\marketplaces\temp_xxx' ->
'C:\Users\<user>\.claude\plugins\marketplaces\omc'

Tried:

• Running as administrator
• Adding .claude folder to Windows Defender exclusion (Add-MpPreference -ExclusionPath)
• Running Claude Code from within the ~/.claude/plugins directory
• None of these workarounds resolved the issue.

The root cause seems to be the rename operation on Windows NTFS. A possible fix could be to use copy + delete instead of rename, or clone directly to the final directory name to avoid the rename step entirely.

Additional root cause details from independent investigation

I hit this same bug on Windows 10 + CC 2.1.101 and traced it further. There are actually two layered failure modes in the rename dance:

1. EPERM: stale .bak/ blocking rename (same as reported here)

The updater does: live → .bak, staging → live. If .bak/ already exists from a prior failed attempt, Windows fs.rename() returns EPERM (can't rename over existing directory). The rollback path also fails for the same reason. Once wedged, every subsequent update fails permanently.

Fix: Delete the stale .bak/ directory manually.

2. EACCES: read-only git pack files blocking fs.rm()

Even after fixing #1, the next session re-wedges because the updater can't rm the live marketplace directory. The shallow git clone creates pack files with read-only permissions (-r--r--r--):

.git/objects/pack/pack-*.idx
.git/objects/pack/pack-*.pack  
.git/objects/pack/pack-*.rev

Node's fs.rm() fails with EACCES on read-only files on Windows unless called with { recursive: true, force: true }. Bash rm -rf handles this fine (it strips the read-only attribute first).

Fix: Delete the .git/ directory inside the marketplace dir before running update, OR fix the Node code to use fs.rm(path, { recursive: true, force: true }).

Permanent workaround

rm -rf ~/.claude/plugins/marketplaces/claude-plugins-official.bak
rm -rf ~/.claude/plugins/marketplaces/claude-plugins-official/.git
claude plugin marketplace update claude-plugins-official

Filed separately as #46830 before finding this issue — that one has the full trace and a second comment with the EACCES details.

Adding a data point from Windows 11 Enterprise 25H2 with corporate endpoint protection (Carbon Black), Claude Code 2.x, April 2026 — same error as the original report:

EPERM: operation not permitted, rename
  '...marketplaces\temp_1776887882005' -> '...marketplaces\epic'

Still reproducing on latest. Manual rm -rf on the staging temp_* + target dir + retry is currently the only workaround for enterprise users.

Failure mode not yet called out in this thread: corporate AV real-time scanners

Prior analysis in the thread (and in #46830) covers persistent-state failures — stale .bak/, read-only git pack files, existing destination dir. But there's a distinct transient-lock class that appears to be the reason this bug is roughly 100% reproducible on enterprise Windows workstations and near-0% on home dev machines (which may explain why it's been hard to repro internally):

Corporate EDR/AV scanners — Carbon Black, CrowdStrike, SentinelOne, Defender for Endpoint with real-time protection on — open handles on every newly-written file during their post-write scan. When Claude Code writes a marketplace staging dir full of small JSON/manifest files and then immediately calls fs.renameSync() to finalize, Windows returns EPERM because the scanner still has one of those files open — even though the destination path is clean and nothing else is competing.

Symptoms specific to this class:

• First install works; second install of the same marketplace fails (files flagged from first batch still being scanned).
• Running Claude Code elevated doesn't help — AV runs at kernel level.
• Add-MpPreference -ExclusionPath "$env:USERPROFILE\.claude" often doesn't fix it (many corporate AVs either don't honor user exclusions or scan the source of the copy anyway).
• Non-deterministic: retry 3 seconds later and it sometimes just works.

Suggested fix

Defense in depth, in order of effort:

1. Retry with exponential backoff on EPERM/EBUSY rename (smallest change, biggest coverage — locks clear within 2–3s):

async function renameWithRetry(from, to, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    try {
      await fs.promises.rename(from, to);
      return;
    } catch (err) {
      if (err.code !== 'EPERM' && err.code !== 'EBUSY') throw err;
      if (i === attempts - 1) throw err;
      await new Promise(r => setTimeout(r, 500 * Math.pow(2, i)));
    }
  }
}

2. Clean up orphan temp_* staging dirs on every marketplace add/update invocation. Prevents the "each retry creates temp_N+1 while temp_1..N are still there" spiral multiple commenters in this thread have documented. Cleanup is safe unconditionally — temp dirs are never valid between runs.

3. Use force and retry on the pre-rename target removal (handles the EACCES read-only-pack-files angle from #46830 simultaneously):

await fs.promises.rm(targetPath, {
  recursive: true,
  force: true,
  maxRetries: 3,
  retryDelay: 500,
});

4. (Bigger refactor) Skip the rename dance entirely. Download directly to the final target with a .installing sentinel; atomic-delete the sentinel to promote. Avoids the Windows-vs-POSIX rename semantic mismatch at the source. Larger change but makes this whole class of issue go away.

(1) + (2) + (3) together should fix the vast majority of reports on this thread without a structural refactor. Happy to PR if a maintainer can point at the marketplace finalize logic in the tree.

I hit what looks like same Windows marketplace-finalize bug while adding .

Environment:

• Windows 10 Pro for Workstations 10.0.19045
• Native Claude Code CLI
• PowerShell and Git Bash both involved during testing

Repro command:
Adding marketplace…✔ Marketplace 'context-mode' already on disk — declared in user settings

Observed error:

What I checked before retrying:

• target directory did not exist
• temp directory did not exist
• no longer had context-mode marketplace/plugin entries
• no longer had context-mode plugin entry
• manual create + rename from -> succeeded in same parent directory

Important detail: after the CLI failure, neither directory was left behind on disk.

Even after terminal restart and full machine reboot, the error reproduced several times.

Then later, after another terminal restart, the exact same command succeeded:

So this may be a transient Windows race/locking bug in marketplace cache finalization, not only a stale-directory condition.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.