`.mcpregistry_*` token files should be stored in a unified folder ignored from git

[vemonet]

Is your feature request related to a problem? Please describe.

When using mcp-publisher login it generates multiples .mcpregistry_* files in the root of my project, e.g. .mcpregistry_github_token, .mcpregistry_registry_token

To avoid commiting them I need to manually add .mcpregistry_* to my .gitignore, this is not ideal and there are more elegant and safer ways to handle this situation

Describe the solution you'd like

• Create a .mcpregistry/ folder for all files (tokens, etc) related to the MCP publisher (naming at your convenience)
• Add a .mcpregistry/.gitignore file containing * to automatically ignore the whole folder

[izgorodin]

Ran into this twice in the same session today (2026-04-12) on two separate repos while shipping v0.3.0-v0.3.3 of @mnemoverse/mcp-memory-server to the Official Registry. Adding real-world data and a small architectural suggestion.

What happened

1. First hit — mcp-publisher login github + mcp-publisher publish run from the npm package repo root. Files .mcpregistry_github_token and .mcpregistry_registry_token appeared in $cwd. Our git add -A picked them up before we noticed, and the JWT (ghu_...) made it into a local commit. The files are chmod 600 which is good, but:

   • git status shows them as untracked if .gitignore doesn't know about them yet.
   • git add -A / git add . will happily stage them.
   • Our release commit accidentally captured them — we caught it in review, amended the commit, then had to git reflog expire --expire=now --all && git gc --prune=now to fully purge the orphaned commit from .git/objects/. The fix took longer than the original work.

2. Second hit — hours later, I accidentally ran a mcp-publisher command from the docs repo directory (wrong cd context). Fresh tokens got written there. Same issue, second repo. Had to add .gitignore entries again on a completely unrelated repo.

Real consequence: every new repo where mcp-publisher is ever invoked needs a .gitignore entry added manually. If the user doesn't know, the first commit leaks a live token. The "CLI writes credentials to $cwd" anti-pattern is documented elsewhere as a cautionary tale — aws configure writes to ~/.aws/, gh auth login writes to ~/.config/gh/, npm login writes to ~/.npmrc, git config --global writes to ~/.gitconfig. Every major CLI stores credentials in $HOME, not $cwd.

Architectural suggestion

The proposed .mcpregistry/ project-local folder + * gitignore in the issue body solves the "committed by accident" problem for that one repo, but the token still lives in $cwd, so:

• It follows the user between repos via cd, with the surprising effect that "publishing from the wrong directory creates files there."
• Running the same publish command from different repos generates different token files in different places.
• If the user is running on a shared dev machine, the token sits in a project folder that may be less protected than $HOME.

Stronger fix: follow the XDG Base Directory spec like other credential-managing CLIs. Store at $XDG_CONFIG_HOME/mcp-publisher/ (defaults to ~/.config/mcp-publisher/ on Linux/macOS, %APPDATA%\mcp-publisher\ on Windows). One canonical location, independent of $cwd, chmod 700 on the directory + chmod 600 on the files. This is exactly how gh, kubectl, docker, aws, npm all handle credential persistence.

Backward compat path: on first run of the new version, if .mcpregistry_* files exist in $cwd, read them, migrate to ~/.config/mcp-publisher/, print a one-line notice, delete the old files. Zero user action required.

Happy to help

If the project-local .mcpregistry/ folder is the preferred direction for reasons I don't know about (e.g., multi-tenancy per-repo by design), that's fair — I can send a small PR against the current behavior to just create the folder + * gitignore on login, which would at least stop the committed-by-accident footgun we hit. Or, if you're open to the ~/.config/mcp-publisher/ XDG direction, I can prototype that as a separate PR with the migration path above.

Either way — flagging that this one has been open for 6 months, and multiple users are now hitting it in real production workflows. Bumping for triage visibility. 🙏

[vemonet]

It is quite concerning that such a dangerous and careless safety design has been left open for so long on such project (more than 6 months) and absolutely no activity. Especially when supply chain attack coming from compromised maintainers account are becoming so widespread.

A quick search on github shows that at least 2 people already have pushed their github token publicly thanks to this project poor security design: https://github.com/search?q=.mcpregistry_github_token&type=code

Fixing this blatant mistake would be really easy, so it raises a few questions about the overall quality of the project, and its capability in delivering a secure registry system.

It seems like development on this registry project has been stopped already, but please archive the repo and make this more explicit in the readme

@rdimitrov

[rdimitrov]

Hey @vemonet 👋 Thanks a lot for raising this and for the detailed write-up, really appreciate it 🙏

You’re right that the current behaviour isn’t ideal and the risk of accidentally committing tokens is something we definitely want to address. I'll prioritise and work on a PR to address this 👍

Also just to mention - this is a community-driven open source project and contributions are very welcome. If you’re up for it, we’d be happy to review a PR or collaborate on improving this further.

Thanks again for calling this out

[vemonet]

If you’re up for it, we’d be happy to review a PR or collaborate on improving this further.

Someone already did it here: #1148

Moving the token files to a folder is a bit of a design change, so I won't go ahead with such design change before at least a sign from maintainers they might be interested in it. I made a clear proposition to address the issue, and such changes (project file structure) need to have some feedback before moving on to implementation

The issue with unexpected commit of tokens can be also addressed differently with less design change, e.g. keep current files and just add the line .mcpregistry_* to the project root .gitignore automatically. But it would be cleaner to have 1 subfolder that contains all the tokens files. Easier to read and find files, better contained, easier to move around, easier to prevent from leaking

[rdimitrov]

Thanks @vemonet 👍

I've opened #1166 which takes a stronger approach where instead of a project-local .mcpregistry/ folder, it moves token storage to ~/.config/mcp-publisher/ and keeps the GitHub token in memory (never written to disk). This matches how gh, docker, etc. handle credentials where it's one location under $HOME and not scattered across project directories.

[vemonet]

Thanks a lot @rdimitrov

Reusing the approach from industry leaders looks solid, and you avoid duplicating the tokens

That said, what if the user needs to use different accounts on the same machine? Not sure if this is a common practice