[MODEL] Claude suggests inconsistent paths under user level Claude store (.claude) for plugin workspaces
Type of Behavior Issue
Claude made incorrect assumptions about my project
What You Asked Claude to Do
While developing Claude Code plugins intended for public marketplace release, I ask Claude Code to help decide where the plugin should persist per-user state (onboarding answers, preferences, etc.) — data that must survive plugin updates and ideally be portable across machines.
What Claude Actually Did
Claude consistently suggests paths nested under ~/.claude/, for example:
~/.claude/plugin-data/<plugin-name>/~/.claude/<plugin-name>-data/~/.claude/data/<plugin-name>/
The specific subpath varies between sessions and even within a single session, but the bias toward ~/.claude/ as the root is consistent. Claude does not proactively suggest XDG Base Directory paths.
There are two problems with this (note: I'm using the plugin development skill)
- Non deterministic: if you follow this blindly, you will end up propagating a discorderly and inconsistent data structure for users within their
.claude. - Change of data loss: Assuming that these paths are not safe from Claude Code updates, this creates a non-insignificant chance of data loss/erasure for users.
Docs
A plugin is a self-contained directory of components that extends Claude Code with custom functionality. Plugin components include skills, agents, hooks, MCP servers, LSP servers, and monitors.
Admittedly, this doesn't address the issue of user memory persistency so perhaps the desired behavior is that users should use memory for this purpose (but general user-memory is not a great way to maintain templates and other artifacts that might be bundled by the plugin author!)
Under "optional fields" for the plugin.json the reference doc provides:
"workspaceFolder Workspace folder path for the server"
This suggested to me at least that the idea that plugins could declare a persistent data/storage folder is intended but that the path is not specified yet.
Expected Behavior
For per-user plugin state, Claude should default to the XDG Base Directory spec on Linux and its cross-platform equivalents:
- Linux:
$XDG_DATA_HOME/<plugin>/(default~/.local/share/<plugin>/) for data;$XDG_CONFIG_HOME/<plugin>/(default~/.config/<plugin>/) for config - macOS:
~/Library/Application Support/<plugin>/ - Windows:
%APPDATA%\<plugin>\
~/.claude/ is Claude Code's own config/install directory. Third-party plugins should not write user data there by default, and they must never write inside ~/.claude/plugins/<plugin>/ — that directory is owned by the marketplace installer and is overwritten on plugin update.
Permission Mode
I don't know / Not sure
Can You Reproduce This?
Sometimes (intermittent)
Steps to Reproduce
- Start a Claude Code session and ask it to help design a Claude Code plugin that includes an onboarding flow which persists user answers across sessions.
- Ask: "Where should the plugin store its per-user data?"
- Claude tends to propose a path nested under
~/.claude/rather than an XDG-compliant path.
Claude Model
Opus 4.7
Relevant Conversation
Representative paraphrase of the pattern across sessions:
User: Where should my plugin store user data? Claude: You could put it at ~/.claude/plugin-data/<plugin>/ so it stays alongside your Claude config…
The XDG spec is not proposed unless the user explicitly raises it. Even if this is not the case, official guidance as to what path to use for persisting user data that a plugin expects to reference would be helpful.
Impact
Low - Minor inconvenience
Claude Code Version
2.1.116 (Claude Code)
Platform
Anthropic API
Additional Context
Likely cause: overgeneralization from the fact that Claude Code's own dotfiles and plugin installs live under ~/.claude/. The model appears to treat that directory as a general-purpose home for anything plugin-related rather than recognising it as Anthropic-owned configuration space.
Suggested correction: when advising on plugin user-data storage, default to XDG paths and explicitly exclude ~/.claude/ unless the data is part of Claude Code's own configuration surface.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗