[BUG] Plugin install fails with EXDEV when /tmp is tmpfs

Found the specific trigger. The error only happens with plugins using "source": "./.claude-plugin" in marketplace.json.

Tested on Ubuntu with tmpfs /tmp and ext4 /home:

• worktrunk@worktrunk - FAILS - uses "source": "./.claude-plugin"
• perplexity@perplexity-mcp-server - WORKS - uses "source": "./"
• claude-mem@thedotmack - WORKS - no source field
• all official plugins - WORK - no source field

So the bug is in the code path that handles subdirectory sources, not the root-level source path.

Additional findings:

1. The source field is required - it cannot be removed as a workaround.

Per the official documentation, source is a required field for plugin entries:

| Field | Type | Description |
|-------|------|-------------|
| name | string | Plugin identifier |
| source | string\|object | Where to fetch the plugin from |

Removing it results in:

Failed to load marketplace: Invalid schema: plugins.0.source: Invalid input

2. "source": "./" also triggers the bug - not just "./.claude-plugin" as originally reported.

3. Observation: On my system, /tmp is tmpfs (RAM) while ~/.claude is on disk (different filesystems). Setting TMPDIR to a path on the same filesystem as ~/.claude allowed installation to succeed.

+1 - just happened to me as I have the same setup (/tmp) is tmpfs (RAM)

Same happened for me. This was also using a plugin that used "source": "./"

Additional Confirmation

Experiencing the same issue on Omarchy (Arch Linux fork) when installing plugins from marketplace.

Error:

Error: Failed to install: EXDEV: cross-device link not permitted, rename '/home/vadim/.claude/plugins/cache/rust-skills' -> '/tmp/claude-plugin-temp-1769078211737'

Environment:

• OS: Omarchy (Arch Linux fork) - kernel 6.18.3-arch1-1
• Attempting to install: rust-skills@rust-skills from marketplace
• /tmp is on tmpfs (separate filesystem from home directory)

This confirms the issue affects the marketplace plugin installation flow as well. The TMPDIR workaround should resolve it.

Also happens on macOS, with both Claude code and cowork, when /home is on a different partition.

Root cause found in the installer source

We traced this to a specific code path in the mw() function (plugin install). The installer works in two steps:

1. Stage: Copy plugin source to cache/<plugin.json name> (via l9H)
2. Finalize: Rename to cache/<marketplace>/<plugin>/<version> (via Pv)

Between these steps, there's a startsWith guard:

let J = B.path.endsWith(sep) ? B.path : B.path + sep;
if (U.startsWith(J)) {
    // Final path is INSIDE staging path — circular rename
    let Q = path.join(os.tmpdir(), `claude-plugin-temp-${Date.now()}`);
    await rename(B.path, Q);   // <-- EXDEV when /tmp is tmpfs
    mkdirSync(dirname(U), { recursive: true });
    await rename(Q, U);
} else {
    await rename(B.path, U);   // Direct rename, same filesystem — works fine
}

When this triggers: If the name field in .claude-plugin/plugin.json matches the marketplace name, the staging path becomes a prefix of the final path:

• Staging: cache/my-skills (from plugin.json name)
• Final: cache/my-skills/my-skills/1.0.0 (from <marketplace>/<plugin>/<version>)
• "cache/my-skills/my-skills/1.0.0".startsWith("cache/my-skills/") → true → /tmp path → EXDEV

Why official plugins are unaffected: The official marketplace name (claude-plugins-official) never matches any plugin name (code-review, superpowers, etc.), so the startsWith check is always false and the direct same-filesystem rename is used.

Suggested fix

Instead of using os.tmpdir() for the intermediate rename, create the temp directory within the cache root (same filesystem):

if (U.startsWith(J)) {
    let Q = path.join(cacheRoot, `plugin-temp-${Date.now()}`);  // same filesystem
    await rename(B.path, Q);
    mkdirSync(dirname(U), { recursive: true });
    await rename(Q, U);
}

Workaround for plugin authors

Use a distinct name in .claude-plugin/plugin.json that doesn't match your marketplace name (e.g., append -plugin). This avoids the startsWith condition entirely.

Environment: Claude Code v2.1.37, Linux 6.8.0, /tmp mounted as tmpfs, ~/.claude on ext4

Similar issue on WSL2: plugin install fails when CWD is a DrvFs path (/mnt/d/). Works fine from native WSL paths (~/).

Cloned repository from ... to /home/user/.claude/plugins/cache/temp_git_1770644348096_4iyku1
Failed to cache plugin: ENOENT: no such file or directory,
  rename '/home/user/.claude/plugins/cache/temp_git_...' -> '/home/user/.claude/plugins/cache/atlassian-confluence'
    at renameSync (/$bunfs/root/claude:12:1491)

Git clone succeeds, but renameSync immediately fails with ENOENT — both paths are on the same ext4 filesystem. Appears to be a Bun renameSync issue when process.cwd() is on DrvFs.

Fix coming in the next version

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.