[BUG] Plugin-written project files (e.g. rendered .claude/rules/) silently become global when a plugin is used with cwd=$HOME

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest related: #40495 settings resolution, #26489 directory traversal for plugin content — neither covers this specific case)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code hardcodes ~/.claude/ as its user-level settings tier (settings.json, CLAUDE.md, rules/) — read for every session on the machine regardless of cwd. Separately, any plugin that writes project-scoped files relative to cwd (a normal, common pattern — e.g. rendering instruction files into <cwd>/.claude/rules/, a directory Claude Code loads as context alongside CLAUDE.md) will, if a user ever runs that plugin with cwd = $HOME, write those files into that exact same physical location.

There is no mechanism — for the plugin author or the user — to know at write-time that this specific directory is special. The two concepts (a project that happens to live at $HOME, vs. genuine global/user-level configuration) are structurally identical at that one path. Claude Code gives no warning when a plugin-install or plugin-render step targets .claude/ under $HOME specifically, even though the effect is categorically different from writing the same files anywhere else: instead of scoping to one project, the files and any enabledPlugins toggle apply to every other project and session on the machine, silently, with no visible signal from inside a normal project session that the injected "global" content actually originated from a project-local install at $HOME.

This isn't a bug in the plugin itself — it behaves identically in every other directory. It's a Claude Code architecture edge case: no disambiguation exists between "$HOME as a project" and "$HOME as the user-settings tier," and no warning fires when a plugin write targets that specific, structurally-overloaded path.

What Should Happen?

Either:

• Warn or require confirmation when a plugin-driven write targets .claude/ inside $HOME specifically, since that path is structurally different from every other directory, or
• Provide a documented way for a plugin (or user) to detect, at runtime, whether the current .claude/ context is the user-level tier vs. a project that happens to live at $HOME.

Steps to Reproduce

1. cd ~ && git init (treat your home directory as its own small git-tracked project)
2. Install/use any plugin that writes project-scoped files relative to cwd into .claude/ (e.g. a plugin that renders instruction files into <cwd>/.claude/rules/, or one that sets enabledPlugins.<name>: true in <cwd>/.claude/settings.json during install)
3. Open a new Claude Code session in a completely unrelated project directory
4. Observe: the plugin's rendered files and its enabledPlugins entry are loaded as context / active for this unrelated session too, with no indication they originated from the $HOME install

Concretely discovered today: a plugin (powell-clark/consciousness, a PGPS/roadmap tool, currently a private repo with a planned public release) was installed and used with cwd = $HOME at some point. This wrote rendered instruction files into ~/.claude/rules/ and set enabledPlugins.consciousness: true in ~/.claude/settings.json. Every other project's session on the machine silently inherited those files as global context — and any project that also had its own proper, per-project install of the same plugin ended up loading the same instruction content twice per session (once from its own local copy, once from the leftover global injection from the $HOME install).

Is this a regression?

No — this appears to be inherent to how the user-settings tier and cwd-relative project writes both resolve to ~/.claude/ when cwd = $HOME.

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API (Claude Max subscription)

Operating System

Linux 6.11.0-1027-oem (Ubuntu, x86_64)

Terminal/Shell

bash, inside Cursor's integrated terminal and tmux

Additional Information

Happy to share more detail on the specific plugin (powell-clark/consciousness, currently private, planning a public release soon) if useful for reproduction — the same collision would apply to any plugin following the same cwd-relative write pattern, not just this one.