github / github/copilot-cli

Server-managed extraKnownMarketplaces is fetched but never registers a marketplace (silent auth bail in plugin path)

オープン
#4,556 コメント 3 件 リアクション 2 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

area:configuration area:plugins
主要言語
Shell
スター
11.2k
フォーク
1.9k
平均マージ
14時間 16分
マージ済み PR(30日)
6

説明

Describe the bug

A server-managed extraKnownMarketplaces entry is fetched successfully and parses correctly, but is never merged into the plugin/marketplace code path, so the marketplace is never registered. copilot plugin marketplace list shows only the two defaults, copilot plugin marketplace browse <name> reports "Marketplace not found", and the Copilot desktop app's Settings → Plugins pane shows only copilot-plugins and awesome-copilot.

The failure is completely silent — no error, no warning, no log line.

This appears distinct from #4039 and #4283, which both concern what happens after a managed marketplace/plugin is registered (sync-to-disk and enablement persistence). Here the marketplace is never registered at all, so no plugin from it is installable by any means.

Root cause

In app.js (1.0.80), the marketplace path self-fetches managed settings via XE():

async function XE(){
  let t = await yft();
  if (!t) return;              // bails -> returns undefined
  let e = await iP({selfFetch:!0, authInfo:{type:"user", host:t.host, login:t.login}});
  ...
}

async function A1(t,e,n){
  let r = await Nfe(t),
      s = Bg(e,n)?.extraKnownMarketplaces;   // e undefined -> s undefined
  return s ? {...r, extraKnownMarketplaces:{...s, ...r.extraKnownMarketplaces}} : r;
}

yft() resolves the account via authGetLastLoggedInUser(<configDir>/config.json). When the CLI has no local login record, it returns undefined, XE() bails, and A1() silently returns user settings only. B8() additionally wraps the call in .catch(()=>{}), so even a thrown error is swallowed.

This is reachable in normal use because the session path and the marketplace path resolve auth differently. When the CLI is driven by the desktop app (copilot --server --stdio), the app supplies auth to the session, and the session path fetches the policy fine — the same process logs:

[managedSettings] server policy received from https://github.com: bypassDisabled=false, keys=[enabledPlugins,extraKnownMarketplaces]

…while the marketplace path in that same process sees no account and skips the fetch entirely. So enterprise policy is demonstrably present and enforced (bypass-permissions restrictions apply), yet extraKnownMarketplaces is inert.

Affected version
copilot 1.0.80
GitHub Copilot desktop app 1.1.11
Steps to reproduce the behavior
  1. Publish a marketplace repo containing .claude-plugin/marketplace.json.
  2. Configure enterprise managed settings with:
{
  "extraKnownMarketplaces": {
    "acme": { "source": { "source": "github", "repo": "ACME/agent-plugins" } }
  },
  "enabledPlugins": {}
}
  1. Confirm the server actually returns it:
$ gh api /copilot_internal/managed_settings
{"extraKnownMarketplaces":{"acme":{"source":{"source":"github","repo":"ACME/agent-plugins"}}},"enabledPlugins":{}}
  1. Confirm the client receives it (from the app-spawned CLI log in ~/.copilot/logs/):
[managedSettings] server policy received from https://github.com: bypassDisabled=false, keys=[enabledPlugins,extraKnownMarketplaces]
  1. List marketplaces:
$ copilot plugin marketplace list
Included with GitHub Copilot:
  ◆ copilot-plugins (GitHub: github/copilot-plugins)
  ◆ awesome-copilot (GitHub: github/awesome-copilot)

$ copilot plugin marketplace browse acme
Failed to browse marketplace: Error: Marketplace "acme" not found

The acme marketplace is absent, and absent from the desktop app's Plugins pane.

Expected behavior

A marketplace declared in server-managed extraKnownMarketplaces should be registered and appear in copilot plugin marketplace list and in the desktop app's Plugins pane, exactly as the equivalent user-scope setting does.

Failing that, the policy fetch being skipped for lack of an account should produce a visible warning rather than silently degrading to user settings.

Additional context

The setting itself is valid — every other layer handles it correctly. Isolating each layer:

The identical JSON works at user scope, which rules out the shape/discriminator:

$ COPILOT_HOME=/tmp/cptest copilot plugin marketplace list
Registered marketplaces:
  • acme (GitHub: ACME/agent-plugins)

$ COPILOT_HOME=/tmp/cptest copilot plugin marketplace browse acme
Plugins in "acme":
  • ...   (all plugins resolve correctly)

The Rust resolver preserves the key from both layers. Calling the native module directly:

const h = require(".../prebuilds/darwin-arm64/runtime.node");
const j = JSON.stringify({
  extraKnownMarketplaces: { acme: { source: { source: "github", repo: "ACME/agent-plugins" } } },
  enabledPlugins: {}
});
h.managedSettingsResolveEffective(j, undefined);  // server layer
h.managedSettingsResolveEffective(undefined, j);  // device layer

Both return the key intact:

{"enabledPlugins":{},"extraKnownMarketplaces":{"acme":{"source":{"source":"github","repo":"ACME/agent-plugins"}}}}

The auth lookup is what fails. Against the real config:

await h.authGetLastLoggedInUser(os.homedir()+"/.copilot/config.json", spec);
// => undefined   (NO LOGGED-IN USER)

There is no CLI-side login record: the desktop app stores its token in its own data.db (github_accounts.access_token), and there is no Keychain entry for the CLI. So yft() cannot resolve an account even though the app is fully authenticated and the session path fetches policy successfully in the same process.

Note on the device/MDM path. Policy delivered via the device file (/Library/Application Support/GitHubCopilot/managed-settings.json) does not go through yft(), so validating a config that way can pass while server-delivered policy fails. Conformance testing that uses only the MDM path will not catch this.

Environment

  • Operating system: macOS 26.5.1
  • CPU architecture: arm64
  • Copilot CLI: 1.0.80 (engine spawned by the desktop app as copilot --server --stdio)
  • Copilot desktop app: 1.1.11
  • Policy source: server-managed (enterprise), confirmed via /copilot_internal/managed_settings

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

app.js で XE()、A1()、B8() の追跡から始め、次に marketplace パスの認証情報の検索と、copilot --server --stdio が使用するセッションパスを比較します。サーバー管理の設定を再現し、policy を握りつぶしたりサイレントなフォールバックを発生させたりせずに、acme marketplace が copilot plugin marketplace list とデスクトップの Plugins ペインに表示されることを確認します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
github, javascript
領域
authentication, cli
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
55/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。