Plugin marketplace add fails with EFAULT on macOS 26, and deleting the cache directory does not break the loop

Summary

/plugin marketplace add fails on macOS 26 with EFAULT: bad address in system call
argument during "finalize marketplace cache". This reproduces #53181 (closed as
inactive, now locked) on a current version, and adds one observation that narrows
the cause considerably:

The rm fails with EFAULT even when the target directory does not exist.

A rm of a non-existent path should fail with ENOENT, not EFAULT. So this is not
about the directory's contents, permissions, or chflags — the failing call never had
a directory to act on.

Environment

• Claude Code 2.1.232
• macOS 26.6.1 (build 25G76), Darwin 25.6.0, Apple Silicon
• Node v20.18.0

Reproduction

/plugin marketplace add tecolicom/agent-skills
  -> Successfully added marketplace: tecolicom

/plugin install greple@tecolicom
  -> Couldn't load marketplace "tecolicom": Failed to load marketplace "tecolicom"
     from source (github): Failed to finalize marketplace cache. Please manually
     delete the directory at /Users/<user>/.claude/plugins/marketplaces/tecolicom
     if it exists and try again.

     Technical details: EFAULT: bad address in system call argument,
     rm '/Users/<user>/.claude/plugins/marketplaces/tecolicom'

Deleting the directory and retrying produces the same error, indefinitely.

The part that is new — stated with its limits

Correction to how I first worded this. I originally wrote that the rm fails on a
path that does not exist, as if I had observed the two simultaneously. I had not. What
I actually observed is below; the inference is likely but not proven, and the
distinction matters for anyone debugging it.

What is certain: I removed the directory with rm -rf (exit 0), confirmed it was gone,
and the very next attempt failed with the same EFAULT on the same path. When I
inspected — seconds later — no directory existed:

$ python3 -c "import os; b='/Users/<user>/.claude/plugins/marketplaces'; print(sorted(os.listdir(b)))"
['claude-plugins-official']

$ xattr -l /Users/<user>/.claude/plugins/marketplaces/tecolicom
xattr: No such file: /Users/<user>/.claude/plugins/marketplaces/tecolicom

What that leaves open: the finalize sequence is presumably clone-to-temp → remove
destination → rename. It is possible finalize created a partial destination, failed
to remove it, and something cleaned it up before I looked. So "the rm targeted a
nonexistent path" is an inference across that window, not a direct observation. I have
not managed to catch the directory's state at the instant of the error.

What survives regardless of which it is: the remedy the error message gives does not
work. Deleting the directory from a shell succeeds, and the next attempt fails
identically. That loop is reproducible and has no exit.

#53181 suggested chflags -R nouchg as a factor. That does not fit here: the
directories I removed carried no uchg/schg flags (find -flags +uchg -o -flags
+schg returned nothing), and rm -rf needed no special handling.

What I ruled out

The repository is not the cause:

• git clone --depth 1 https://github.com/tecolicom/agent-skills.git succeeds
• .claude-plugin/marketplace.json is present and valid: name, owner, plugins
• plugin source values use the "./skills/<name>" relative form, which the official

marketplace also uses (53 of its entries)

• marketplace name and repo owner are both tecolicom, so #52827 (owner/name case

mismatch) does not apply

And per #53181, the same error occurs with claude-plugins-official, so it is not
specific to any third-party repository.

Sandbox interception: checked, no evidence

EFAULT from an fs syscall suggested seatbelt interception on Tahoe, so I looked:

• log show --last 40m --predicate 'sender == "Sandbox"' — 0 entries
• no deny messages mentioning claude
• claude is not running under sandbox-exec (no such process), it is

~/.local/share/claude/versions/2.1.232 invoked directly

So I have no evidence for that hypothesis. Recording the negative result so nobody
else spends time on it.

Possibly relevant

On this machine claude-plugins-official does load, from a cache directory of 429
files created before the failures began. The two directories differ in mode: the
working one is 755, while the failed partial clones were 700. I have not verified
whether that is a cause or a symptom, and I did not force a refresh of the working
marketplace to test it — that would have broken the one marketplace that still works.

Two failed attempts left directories containing only .git and no working files, which
is consistent with the failure happening at the finalize/rename step rather than during
the clone.

Impact

The plugin system is unusable for adding any new marketplace on this platform. The
suggested remedy in the error message does not work. The workaround is to bypass
marketplaces entirely — copying a plugin's SKILL.md into ~/.claude/skills/ — which
gives up updates and everything else the marketplace provides.

Filing fresh because #53181 is closed and locked.