[BUG] Corporate AV (ESET) quarantines plugin installs mid-rename — surfaced as bare EBUSY/EPERM, leaves half-installed state

Environment

• Claude Code 2.1.207, native Windows 11 Pro (10.0.26200)
• Corporate-managed ESET Endpoint Security (real-time protection, standard enterprise policy — no local admin control)

Summary

On a Windows machine with ESET real-time protection, claude plugin marketplace add and claude plugin install fail non-deterministically with EBUSY/EPERM: operation not permitted, rename .... The actual cause is the AV scanning/quarantining the freshly downloaded files during the tool's clone→rename step — but nothing in the error output suggests AV involvement, so it reads like a transient file-lock race. We lost roughly an hour retrying before ESET's own notification revealed it was quarantining the content as a threat.

Repro (what we observed)

1. claude plugin marketplace add trailofbits/skills-curated

→ EPERM: operation not permitted, rename '...\plugins\marketplaces\trailofbits-skills-curated' -> '...\plugins\marketplaces\skills-curated'
→ retry: same failure as EBUSY. The clone completes; the final rename always loses.

1. claude plugin install superpowers@claude-plugins-official (pinned sha from the official marketplace)

→ EBUSY: resource busy or locked, rename '...\plugins\cache\temp_git_...' -> '...\plugins\cache\claude-plugins-official\superpowers\6.1.1' — reproducible on every attempt (3/3).

1. Meanwhile pyright-lsp@claude-plugins-official installed cleanly — the interference is content-dependent, consistent with AV signature/heuristic hits (the ToB marketplace repo vendors genuine pentest-content skills; superpowers ships lifecycle-hook scripts).
2. Failed installs leave temp_git_* directories in plugins/cache/ that cannot be moved or deleted while the AV holds handles (Permission denied), plus (in an earlier case on this machine) a plugin recorded in enabledPlugins in settings.json without an entry in installed_plugins.json — an "enabled but not installed" zombie.

Why this is worth fixing in the installer (independent of any AV vendor)

AV-scan-during-rename is endemic on corporate Windows; ESET is just today's instance (see also #63470 for Norton TLS interception, #67800 for Smart App Control — same class of problem: security software interference surfacing as cryptic failures).

Suggested improvements:

1. Detect the pattern and say so. Repeated EBUSY/EPERM on renaming a freshly downloaded directory is a strong AV signal. A hint like "Your antivirus may be scanning or quarantining the downloaded files — check its detection log" would have saved the debugging session.
2. Retry the final rename with backoff (or copy-then-delete as fallback). The clone itself succeeds every time; only the rename races the scanner.
3. Clean up on failure. Remove temp_git_* leftovers (best-effort, they may be AV-locked — then say so) and never leave enabledPlugins/installed_plugins.json disagreeing.
4. Consider per-plugin sparse fetch for marketplace installs. Installing one benign markdown-only plugin from trailofbits/skills-curated currently materializes the entire marketplace repo — including security-testing skills (ffuf, exploit-methodology content) that corporate AVs will flag even though the user never asked for them. Fetching only the requested plugin's directory would shrink the AV attack surface dramatically.

ESET detection details

The local ESET logs are encrypted; detection name(s) per the GUI: _[to be added — ESET → Tools → Log files → Detections]_

Resolution on our side

Dropped the flagged plugins (no AV workarounds on a managed device); kept pyright-lsp + frontend-design which install and run untouched.