Private-repo marketplace plugin install fails authentication

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A workspace-enabled marketplace plugin, sourced from a private GitHub repo repeatedly fails to install on first load. The failure is an authentication failure inside the plugin loader’s git fetch invocation, even though the same machine can authenticate to the same repo via every other git path (Git Credential Manager / Windows Credential Manager already has a working credential — git ls-remote succeeds). Notably, the loader subsequently succeeds via a different internal code path (shallowClone …) without any credential change on the box, suggesting two non-equivalent auth paths inside Cursor’s plugin loader.

Steps to Reproduce

See the zip file that contains the full logs. Cursor itself provided the internal diagnosis

Expected Behavior

I expect marketplace to allow private git backed repos to be pulled in

Screenshots / Screen Recordings

cursor-plugin-install-failure-bundle.zip (10.7 KB)

Operating System

Windows 10/11

Version Information

Version: 3.5.17 (user setup)
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

This is a known bug on Windows. The plugin loader’s git invocation disables credential helpers (including Windows Credential Manager / GCM) via hard-coded flags, which is why the fetch fails even though your system git can authenticate to the same repo just fine. Your observation about shallowClone succeeding via a different code path is consistent with what we’ve been tracking.

Our team is aware and actively working on a fix. We’re tracking the same issue in detail: Private team marketplace plugin install fails on 3.2.11 – three-stage clone fallback all broken. That thread has two confirmed workarounds:

Option A: _netrc with a PAT (simplest for teams)

winget install GitHub.cli
gh auth login --hostname github.com --git-protocol https --web
$token = gh auth token
@"
machine github.com
login x-access-token
password $token
"@ | Out-File "$env:USERPROFILE\_netrc" -Encoding ASCII -Force

Option B: SSH key with explicit config (no PAT rotation needed)

Set up a dedicated SSH key (id_ed25519_cursor), add an explicit Host github.com block in ~/.ssh/config with IdentityFile + IdentitiesOnly yes, and authorize the key via SSO for your org.

Both workarounds bypass the credential muzzle because _netrc is read natively by curl before credential helpers, and SSH is the first stage attempted before HTTPS.

We’ll post an update here once a fix ships.

9

Hey @SteveH-OGI

We expect some changes here in v3.8 to improve this! It should be out this week. Please give it another try once you’ve upgraded!