Marketplace plugin sync triggers YubiKey presence, undermining hardware key security model

Status Open

Maintainer reply ✓ Yes — stbenjam

Activity 8 comments · opened Jan 4, 2026

💡 Likely answer: A maintainer (stbenjam, contributor) responded on this thread — see the highlighted reply below.

Summary

Claude Code's periodic marketplace plugin sync uses SSH to clone/fetch from git@github.com:anthropics/claude-plugins-official.git. For users with FIDO2/hardware security keys (YubiKey) configured for GitHub SSH authentication, this triggers unintended touch prompts every few minutes, which:

Undermines the security model - Users configure YubiKey touch requirements specifically to authorize sensitive operations (like commit signing). Frequent "background noise" prompts train users to touch without thinking, defeating the purpose.

Disrupts workflow - Unexpected YubiKey prompts interrupt work and cause confusion about what operation is being authorized.

Creates authorization ambiguity - When a user touches their YubiKey, they should know exactly what they're authorizing. Background syncs make this impossible.

Environment

OS: macOS 14.x (Darwin 25.1.0)
Claude Code version: Latest
YubiKey model: YubiKey 5 Nano (OTP+FIDO+CCID mode)
SSH key type: sk-ssh-ed25519@openssh.com (FIDO2 resident key)

Reproduction

Configure GitHub SSH access with a FIDO2 security key:

``# ~/.ssh/config Host github.com IdentityFile ~/.ssh/id_ed25519_sk``

Configure git commit signing with the same key:

``git config --global gpg.format ssh git config --global user.signingkey ~/.ssh/id_ed25519_sk.pub git config --global commit.gpgsign true``

Run Claude Code normally

Observe: YubiKey blinks and requests touch every few minutes during marketplace sync, even when no commits are being made

Evidence

Process list shows periodic SSH operations to GitHub:

ssh -o BatchMode=yes ... git@github.com git-upload-pack 'anthropics/claude-plugins-official.git'
git ... clone --depth 1 git@github.com:anthropics/claude-plugins-official.git

Workaround

Users can work around this by:

Adding a non-SK SSH key before the SK key in ~/.ssh/config
Disabling marketplace plugins entirely

However, this shouldn't be necessary - Claude Code's internal operations should not trigger user-facing security prompts.

Security Consideration

This is fundamentally a security UX issue. Hardware security keys are designed around the principle that touch = explicit authorization. When background processes trigger touch prompts, users either:

Get annoyed and disable the security feature
Start touching reflexively without checking what they're authorizing

Both outcomes weaken security posture.

View original on GitHub ↗

8 Comments

github-actions[bot] · 7 months ago

Found 2 possible duplicate issues:

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

arcaven · 7 months ago

These other reports are similar/related but do not capture the additional use case where yubikey presence is required git operation, and to avoid theft of key materials from the local workstation.

theavey · 7 months ago

FYI @arcaven, I found a workaround, though I'm not sure it's permanent. Completely agree this should not be necessary and should be fixed. Claude should not be using my SSH credentials without my explicit permission.

cwage · 7 months ago

I can confirm this in linux too:

[ERROR] Failed to refresh marketplace claude-plugins-official: Failed to clone marketplace repository: SSH authentication failed. Please ensure your SSH keys are configured for GitHub, or use an HTTPS URL instead.

Original error: Cloning into '/home/user/.claude/plugins/marketplaces/claude-plugins-official'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

How I saw it:

$ claude
Enter passphrase for key '/home/user/.ssh/id_ed25519':

Alarming to say the least. the plugin should just clone via https.

github-actions[bot] · 6 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

cwage · 6 months ago

_(Posted via Claude Code on behalf of @cwage)_

Still happening as of the latest claude update (Feb 2026). Running claude update silently re-registers the claude-plugins-official marketplace even if you previously removed it. There's no persistent opt-out.

The startup sequence then does a git fetch which, for repos using SSH remotes (git@github.com:...), triggers an SSH passphrase prompt that blocks the entire CLI session. The only workaround is to nuke it again after every update:

rm -rf ~/.claude/plugins/marketplaces/claude-plugins-official
echo '{}' > ~/.claude/plugins/known_marketplaces.json

This really needs either:

A persistent setting to opt out of the marketplace entirely (survives updates)
Or at minimum, don't re-create it if the user has previously removed it

stbenjam contributor · 6 months ago

In $HOME/.gitconfig, this was working to bypass their weird use of SSH

[url "https://github.com/anthropics/"]
	insteadOf = ssh://git@github.com/anthropics/

But, in the latest release they're doing something else this doesn't protect against and I get the yubikey prompt again.

arcaven · 2 months ago

In $HOME/.gitconfig, this was working to bypass their weird use of SSH `` [url "https://github.com/anthropics/"] insteadOf = ssh://git@github.com/anthropics/ `` But, in the latest release they're doing something else this doesn't protect against and I get the yubikey prompt again.

fascinating and disappointing in the same moment.

This has until recently been of limited consequence for me personally. I just keep marketplace disabled. However, it's increasingly limiting my helping colleagues. They'd like to encourage more marketplace use in our team, they wish me to try and promote their solutions, bundled as a plugin, and I simply cannot / will not use it because of the distracting, constant yubikey triggering for unknown/unclear reasons.

So I'll drop a note here as a means to say that nine months later and six months after this third re-opneing iteration of this report, I'm still keenly interested in this getting fixed.