code-server 无法通过命令行安装扩展

[BrandonStudio]

使用 code-server 命令行安装本扩展（code-server --install-extension 1.vsix）后有如下特征：

• 安装命令正常退出
• 启动 code-server 后扩展可以显示
• 无法看见任务栏的 GCMP 图标（如token消耗量）
• 可以看到 GCMP 的相关命令（ctrl + shift + p，如 GCMP: Generate Commit Message）
• 点击任意 GCMP 命令后状态栏提示 Activating Extension...，随后静默没有任何反应，且看不到任何日志
  • 仅 trace 级别可以看到 on...activated 的调用，但随后没有任何信息

在 Web 界面中卸载扩展，重新加载窗口，通过 Web 界面从同一个 VSIX 安装，可以正常加载并启动扩展。

• 如果卸载扩展后没有重新加载窗口就直接安装，则仍然不正常

请问有没有办法排查此问题？

[BrandonStudio]

更新

问题变得更加奇怪

1. 按上述方式重新安装扩展后，刷新页面，扩展恢复了不能使用的状态
2. 在 HOSTS 为 code-server 指定一个域名，通过域名访问时扩展完全呈灰色状态，Ctrl + Shift + P 命令列表中不再有相关命令

[VicBilibily]

以下是让AI分析 code-server 源码与 vscode 源码的差异发现的机制差异。

---

已通过 code-server（vendor 的 VS Code）与 VS Code 上游源码完成机制核对。结论如下。

Issue #371 机制差异结论

现象的本质

code-server --install-extension 1.vsix 与 Web 界面安装用的是两套完全不同的代码路径，最终落盘一致，但对运行中的 workbench 的影响、依赖处理、激活判定完全不同。激活"静默无反应"的根因是依赖检查阻止了 activate() 执行，而不是 GCMP 代码本身报错。

机制差异 1：两条安装路径（code-server 源码）

• CLI 安装：src/node/main.ts 的 shouldSpawnCliProcess() 检测到 install-extension → runCodeCli() → spawnCli(toCodeArgs(args))，进入 VS Code Server 的 CLI 入口 remoteExtensionHostAgentCli.ts。它实例化 native ExtensionManagementService，在独立 CLI 进程里解压 vsix 到 ~/.local/share/code-server/extensions，不通知运行中的 workbench，也不触发扩展清单重扫。
• Web UI 安装：ExtensionsWorkbenchService.install() → installVSIX() → getServersToInstall() → server.extensionManagementService.install(vsix)，由 workbench 自己发起，安装完成后立即刷新扩展视图、提示 reload。
• 这直接解释了 issue 里"卸载后没 reload 窗口直接安装仍不正常"——workbench 对扩展清单有生命周期缓存，CLI 侧的任何变更都要求重新加载窗口才能被感知。

机制差异 2：依赖检查会阻止激活（VS Code 源码）

• GCMP 的 package.json 声明 extensionDependencies: ["github.copilot-chat"]。
• workbench 激活扩展前，https://github.com/microsoft/vscode/tree/main/src/vs/workbench/api/browser/mainThreadExtensionService.ts#L157-L170 的 _handleMissingNotInstalledDependency() 会检查依赖：若 github.copilot-chat 未安装，直接阻止激活并弹出 "Cannot activate the 'GCMP' extension because it depends on ... which is not installed"。
• 依赖能否被自动装上，取决于 abstractExtensionManagementService.ts 的 getAllDepsAndPackExtensions()，其第一行就是 if (!this.galleryService.isEnabled()) { return []; }。code-server 默认 extensionsGallery 是关闭的（除非用户配置了 marketplace 镜像），所以 github.copilot-chat 依赖在 CLI 与 UI 两种方式下都可能装不上，导致 GCMP 的 activate() 根本不执行——这正是"trace 只见 on...activated、之后无任何 GCMP 日志、命令可见但点了没反应"的机制来源。

机制差异 3：Copilot 在 code-server 中本身不可靠（权威佐证）

coder/code-server #7494 "Copilot Chat does not work"（仍 open）：官方 maintainer 明确表态 Copilot 闭源且运行在 code-server 违反许可，不提供调试支持、不修复。GCMP 大量使用 vscode.lm.registerLanguageModelChatProvider 与 selectChatModels({ vendor: 'copilot' })（见 provider.ts:73、jsonSchemaProvider.ts:51 等），其激活事件 onLanguageModelProvider:gcmp.* / onLanguageModelTool:gcmp_* 在 vscode.lm/copilot 模型不可用时不会触发，只能靠 onStartupFinished 兜底，又被差异 2 的依赖检查拦住。

机制差异 4：域名访问扩展"灰色"

不同 origin（localhost vs 自定义域名）下，code-server 的 local-storage / service-worker patch 让 localStorage、service worker 按 origin 隔离，workbench 视图状态、activity bar 图标加载异常 → 扩展显示灰色。这与安装方式无关，需固定用同一 origin 访问。

建议

1. 先确认 github.copilot-chat 是否真正安装并激活：code-server --list-extensions，并在扩展面板确认其未被禁用。
2. 用 Web 界面 Install from VSIX 安装并重新加载窗口（reload），避免 CLI 路径的 workbench 感知问题。
3. 观察 GCMP 输出通道 "GitHub Copilot Models Provider (GCMP)" 是否有日志；若完全没有，基本可断定 activate() 未被调用（依赖拦截），而非 GCMP 代码报错。
4. 若确实需要 Copilot 能力，code-server 官方已声明该场景不可支持（#7494），需自行权衡。

[BrandonStudio]

我感觉不对。

这些分析无法解释以下问题

1. 首先，把静默无反应的根因归为阻止了activate()的执行是错误的。错误描述中我已重点提到，

   1. 命令菜单中有 GCMP 的相关命令
   2. TRACE 日志中有 on...activated 的信息

   说明 activate 执行了，但返回为空

   不过，仅限于页面 A，对于后续使用域名访问的页面 B，扩展本身是灰色的，也没有菜单命令，说明扩展没有激活。
   即使如此，单击扩展后显示的详情页中，也没有“启用”按钮指示扩展已被禁用。

2. 安装路径的差异提到 “不通知运行中的 workbench，也不触发扩展清单重扫”，CLI 和 UI 安装的行为差异将可能是问题的关键，不过，AI 的分析中没有考虑页面刚启动时的行为，一般认知中，页面刚启动时应扫描清单。所以差异的核心在于启动时扫描和安装 VSIX 时的立即操作之间的区别，这也将解释为什么通过 UI 安装 VSIX 后扩展正常，但是重新加载窗口后又回到不正常状态。

3. 差异2分析认为是依赖项缺失导致的，这不符合常识。

   1. 如果依赖项缺失，应该在 install-extensions 的时候报错，而不是运行时不能激活
   2. 此分析不能解释为什么通过 UI 安装可以使扩展正常
   3. github.copilot-chat 是内置扩展，不存在缺失的情况

4. 所谓“权威佐证”所提到的许可问题和引用的 issue 已过时，copilot 早已作为 vscode 的一部分进入主存储库。此外，7494中的错误是有错误日志的，与本次问题的现象不符

5. 机制差异 4 的分析没有任何实质内容。localStorage 等只是不同，没有特殊性，不同IP端口和域名访问应该是对称的，如果一个 http host 访问有这个现象，另一个 http host 访问应该具有同样的现象。但现状是两个 http host 访问具有不同的现象。
   这里还需要指出的是，差异并非来源于 IP vs 域名，使用同 IP + 另一个端口也是无法激活（灰色）的状态