[Bug] autoUpdate on extraKnownMarketplaces entry does not trigger plugin update at session start
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Shell
- Sterne
- 11.2k
- Forks
- 1.9k
- Ø Merge
- 14 Std. 16 Min.
- Gemergte PRs (30 T.)
- 6
Beschreibung
Describe the bug
The changelog for 1.0.79 documents:
Set "autoUpdate": true on an extraKnownMarketplaces entry in your user settings to auto-update its plugins at session start
This does not happen. With autoUpdate: true set on an extraKnownMarketplaces entry and an installed plugin from that marketplace deliberately pinned to an older version (both in ~/.copilot/config.json and the cached .plugin/plugin.json/.claude-plugin/plugin.json), starting a brand-new CLI session (full process relaunch, not /restart) does not check for or apply an update. No log line referencing a plugin/marketplace update check appears anywhere in the session's debug log at startup.
Separately, when the update mechanism is triggered manually (copilot plugin update <name>), it worked correctly once a Windows file-lock (held by lingering VS Code / github-copilot-sdk background processes on the shared ~/.copilot/installed-plugins cache) was cleared. That confirms the underlying reinstall codepath is functional — the gap is specifically that automatic checking/triggering at session start never occurs, and (separately) that a locked-file failure during any such attempt would fail silently with no user-visible warning.
Steps to reproduce
- In user settings (
~/.copilot/settings.jsonor via/settings), add/confirm anextraKnownMarketplacesentry with"autoUpdate": true, e.g.:"extraKnownMarketplaces": { "my-marketplace": { "source": { "source": "git", "url": "https://example.com/my-org/my-plugins" }, "autoUpdate": true } } - Have a plugin from that marketplace installed and enabled (e.g. version
0.2.0). - Manually edit
~/.copilot/config.json(installedPlugins[].version) and the plugin's cached manifest (~/.copilot/installed-plugins/<marketplace>/<plugin>/.claude-plugin/plugin.jsonversionfield) down to an older version (e.g.0.1.0), leavingsource_shauntouched. - Fully quit the CLI process (not
/restart— a true new process launch) and startcopilotagain. - Inspect
~/.copilot/config.jsonand the cachedplugin.jsonagain, and check~/.copilot/logs/process-*.logfor the new session for any plugin/marketplace update activity.
Expected behavior
On session start, the CLI should detect the installed plugin version is behind the marketplace's current version and automatically reinstall/update it (per the documented 1.0.79 changelog entry), updating config.json, the cached manifest, and installed_at.
Actual behavior
- The plugin version in
config.jsonand the cached manifest remains at the older pinned version after a full CLI relaunch. installed_attimestamp is unchanged, confirming no reinstall attempt occurred.- The startup debug log shows no entries related to checking plugin/marketplace versions or auto-updating — it goes directly from initialization to loading/activating the existing cached plugins:
...Init suggestion check completed ...Loaded MCP config from installed plugins: 3 server(s): ... ...Plugin activation [agents]: fingerprint=..., plugins=11, loaded=14 - Running
copilot plugin update <plugin-name>manually does work once file locks are cleared, confirming the reinstall codepath itself is functional — it's just never invoked automatically at session start as documented.
Environment
- GitHub Copilot CLI: 1.0.79
- OS: Windows 11
- Node.js: v24.18.1
- Marketplace: private git-hosted
extraKnownMarketplacesentry withautoUpdate: true
Additional context
While testing this, we also observed that a Windows file-lock on the shared ~/.copilot/installed-plugins/<marketplace>/<plugin> cache directory (held by lingering github-copilot-sdk background processes, e.g. from VS Code's Copilot extension) causes a manual copilot plugin update <plugin> to fail with Failed to install plugin: Access is denied. (os error 5). If the same lock were encountered during an automatic session-start check, it would likely fail silently with no user-facing message — worth surfacing a warning/error in that case rather than no-op.
🤖 This issue was drafted with assistance from GitHub Copilot CLI.
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne mit dem Session-Start-Pfad, der extraKnownMarketplaces lädt, und vergleiche ihn mit dem Befehl copilot plugin update . Reproduziere das mit ~/.copilot/config.json, den zwischengespeicherten plugin.json-Dateien unter ~/.copilot/installed-plugins und dem Session-Debug-Log. Als erledigt gilt es, wenn ein vollständiger Neustart die Plugin-Metadaten und installed_at aktualisiert, während Fehler wie Windows-Dateisperren eine sichtbare Warnung erzeugen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- node.js
- Bereich
- cli, tooling
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Ruhig
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 48/100