[BUG] Plugin paths hardcoded with absolute paths fail across environments

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/15717
2. https://github.com/anthropics/claude-code/issues/20676
3. https://github.com/anthropics/claude-code/issues/29671

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Still having the same problem here.

+1

Adding a +1 to keep bugs open because you guys are freaking insane vibing hacks who close everything way too fast.

Adding a data point that this also fires under a different setup than devcontainers: uid-based isolation on a single host with a shared runtime.

We run multiple Claude Code lanes on one VPS via a wrapper that drops to per-lane non-root users (uid 9001-9005). Each lane has its own HOME (/home/<lane-user>/) and writes session/settings there, but the runtime tree (/opt/claude-runtime/...) is symlinked into each lane's HOME via shared claude-runtime-readers/claude-coord groups.

When a lane TUI starts, plugin discovery succeeds (it walks $HOME/.claude/plugins/cache/... which symlinks to /opt/claude-runtime/plugins/cache/..., world-readable). But plugin marketplace validation reads /root/.claude/plugins/marketplaces/<marketplace>/.claude-plugin/marketplace.json directly, regardless of the running user's HOME. Because /root is mode 0700, the lane user (uid 9003) hits EACCES (Permission denied). Cascading consequence: TUI orphan-marks the plugin, never starts the plugin handler thread or bun poller subprocess. The "Listening for channel messages from: plugin:<name>@<marketplace>" banner appears but is theatre — no actual polling/dispatching happens.

Repro context (claude-code v2.1.121):

• 32 distinct PIDs across 11 supervisor crash-loop iterations all hit EACCES on /root/.claude/plugins/marketplaces/claude-plugins-official/.claude-plugin/marketplace.json (captured via strace -f -e openat -p <claude-pid>).
• Workaround attempts that don't work: setting HOME=/home/<lane-user> (env shows correct, TUI ignores), symlinking $HOME/.claude/plugins/marketplaces to /opt/... (TUI uses /root/... directly anyway), opening /root traversal (security regression).

This is the same root-cause class as the devcontainer use case in this issue (and #36575, #55594), just expressed via uid isolation instead of multi-machine paths.

We've concluded that fixing this at host config layer isn't possible without patching the upstream package, and have pivoted our architecture to keep all lanes running as root. Filing this comment so the maintainers have one more data point — the bug isn't only about devcontainers / cross-machine, it also blocks any per-uid isolation strategy on a single host.

If a fix is in flight and a beta version is testable, happy to verify against our repro.

Running into this same issue when deploying Claude Code in a container image. We copy ~/.claude into the image at build time, but the installPath entries in installed_plugins.json and known_marketplaces.json are baked to the build user's home directory, so plugins fail to load for any other user at runtime.

The symlink workaround works but requires knowing the original build-time home path, which defeats portability. Would strongly support storing these paths relative to CLAUDE_CONFIG_DIR or resolving them against $HOME at startup.

+1

+1, keep it alive please

This is extremely annoying. I keep having to invent workarounds (e.g. ~/.claude/plugins -> ~/.claude-plugins symlink that is different in devcontainer vs host), and they keep breaking every few weeks, as the plugin cache management changes. E.g. right now I have:

❯ /plugins                                                                                                                

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  Plugins  Discover   Installed   Marketplaces   Errors (8) 

   ❯ [plug1] (local)
      Plugin "[plug1]" not cached at /[home]/.claude/plugins/cache/[market]/[plug1]/1.1.2
      Run /plugin to refresh the plugin cache

   ✘ [plug2] (local)
      Plugin "[plug2]" not cached at /[home]/.claude/plugins/cache/[market]/[plug2]/1.1.2
      Run /plugin to refresh the plugin cache

   ✘ [plug3] (local)
      Plugin "[plug3]" not cached at /[home]/.claude/plugins/cache/[market]/[plug3]/1.3.1
      Run /plugin to refresh the plugin cache
[...]

while claude plugin list happily shows them as existing, and nothing I can do in /plugins menu (e.g. updating the market) seems to help...

Editing to add: /reload-plugins --force helps, but only for the specific session.

Please fix! +100

For those looking for a workaround for devcontainers - I built this: https://github.com/exciton/devcontainer-features