私有部署 GitLab 别白跑：Gemini CLI 官方扩展的「SaaS 墙」
想要在 Gemini CLI 里直接查看私有部署 GitLab 的 Issue 或合并请求？你可能要先等一等。
近期，不少开发者关注到了GitLab-Ecosystem这个 Gemini CLI 扩展。官方宣传它可以让你在终端里通过自然语言管理 GitLab 资源。但如果你兴冲冲地准备连接公司内部私有的 GitLab 实例，大概率会撞上一堵「看不见的墙」。
事实切片：为什么它连不上私有 GitLab？
通过对该扩展源码（GitLab-Ecosystem/Gemini-CLI-Extensions）及 Manifest 文件的调研，我们发现了三个硬核限制：
- 硬编码的 API 终点：扩展内部固化了
https://gitlab.com/api/v4/mcp作为连接地址。这意味着它默认指向 GitLab.com 的托管 MCP 代理服务。 - 缺乏基准 URL 配置：目前该扩展并未提供
GITLAB_BASE_URL或类似的配置项。用户无法像在普通 GitLab CLI 中那样，通过环境变量将请求重定向到私有域。 - SaaS 特性依赖：它依赖于 GitLab SaaS 侧最近推出的
mcp_server和动态 OAuth 客户端生成特性。这些功能目前尚未在 GitLab Self-managed 版本中全面普及或开放给第三方 MCP 客户端使用。
我们怎么看：这不仅是配置问题，更是架构选择
GitLab-Ecosystem 扩展目前并非一个通用的 GitLab 客户端，而更像是一个**「SaaS 门户」**。
它采用了 OAuth Device Authorization Flow（设备授权流），用户第一次使用时会弹出浏览器跳转到 GitLab.com 进行授权。这种设计极大地简化了 SaaS 用户的上手难度，但对于处于防火墙内、甚至无法访问外网的私有实例来说，这套流程完全无法跑通。
此外，它并没有支持Personal Access Token (PAT)认证。对于私有部署场景，PAT 通常是自动化工具的首选，而该扩展对 OAuth 的强制依赖，再次印证了其纯粹的 SaaS 定位。
它意味着什么：你应该如何选择？
如果你正在评估是否引入这个扩展，可以参考下面的决策链路。
结论很简单：
- 如果你是 GitLab.com 用户：这个扩展非常强大，它让你无需离开终端即可管理全量 SaaS 资源。
- 如果你是私有部署用户：目前建议不要安装。安装后你将无法完成授权，也无法通过配置绕过。
给私有部署用户的建议：
如果你迫切需要类似功能，目前更可行的方案是使用 Gemini CLI 的通用 MCP 支持功能，手动配置一个支持私有实例地址的开源 GitLab MCP Server（如社区维护的 Node.js 版本），而不是使用这个官方的 Ecosystem 扩展。
虽然 GitLab 官方未来可能会增加对私有实例的支持，但至少在当前版本下，它是专为 SaaS 派对准备的。