跳到主内容

Gemini CLI v0.65.0 转正:不受信任目录强制只读,OTLP 自定义 header 是唯一的 feat

Gemini CLI v0.65.0 于 2026-10-20 转正 stable:不受信任目录强制只读工作区设置,恢复会话不再产生重复工具响应,遥测支持自定义 OTLP header。

2026-10-22 · Gemini CLI 官方仓库 Release Notes(tag v0.65.0,published 2026-10-20T21:17:57Z,prerelease: false,经 GitHub Releases API 逐 tag 一手核对;Release Notes 正文逐 PR 读取)

发布 2026-10-22核实 2026-10-22

要点速览

  • v0.65.0 已于 2026-10-20 21:17:57 UTC 转正为 stable(prerelease: false),生产请从 v0.64.0 改钉这一版。
  • 本站 10-17 写下的「v0.65.0-preview.0 未转正」就此失效——它转正了,只是当时还没到时间。
  • Release Notes 里只有一条 feat:#29641 支持自定义 OTLP headers 的遥测配置。其余全是 fix / perf / chore。
  • 安全边界收紧:#29583 不受信任目录下强制执行只读 workspace 设置——脚本若依赖在信任目录之外写入,升级后可能失败。
  • 长会话两项修复:恢复会话不再产生重复的工具响应轮次(#29618);快速退出不再删掉已恢复会话的历史(#29584)。
  • 企业接入要注意:OAuth 回调 iss 参数校验对齐 RFC 9207 元数据(#29616),自建 IdP 升级后需复核兼容性。
  • 又一次「数字骗人」:v0.66.0-preview.0(21:04)比 stable v0.65.0(21:17)早 14 分钟发布,nightly 已到 v0.67.0。

通道现状(2026-10-22 逐 tag 核对)

通道版本发布时间(UTC)说明
Stablev0.65.02026-10-20 21:17生产环境应钉在这一版
Previewv0.66.0-preview.02026-10-20 21:04比 stable 早约 14 分钟——数字更大但不是稳定版
Nightlyv0.67.0-nightly.20261021.gd00859d6b2026-10-21 01:33每日构建,勿用于 CI

选版按通道不按数字:v0.66.0-preview.0 比 stable 早 14 分钟发布,nightly 已经跑到 v0.67.0。通过 Releases API 取「第一条 release」时必须显式过滤 prerelease 与 draft——这次若不过滤,取到的是 v0.67.0-nightly。

唯一的 feat:遥测自定义 OTLP header

#29641 —— feat(telemetry): support custom OTLP headers in telemetry configuration。

一句话的事,但门道在为什么它是个 feat 而不是配置项的补充:要把 Gemini CLI 的用量与 trace 接到企业自建的 OTel Collector,往往需要在 OTLP 请求上带鉴权头或租户头(Authorization、X-Scope-OrgID 之类)。此前这项不可配,等于「遥测可用但只能发到不需要鉴权的采集端」——对企业来说这是能不能用的问题,不是好不好用的问题。

这条和本站观察到的方向是一致的:Gemini CLI 近两版没有加模型能力,但在把可观测性接入企业现有体系这件事上一点没停。对比 Claude Code 同期在补 OTel 的 GenAI 语义属性与缓存写入分档统计,两家都在把「agent 能不能被企业托管」当作主线。

安全边界:不受信任目录强制只读

#29583 —— fix(cli): enforce read-only workspace settings in untrusted folders。

这条是本次最可能打断你现有脚本的改动。语义是:在不受信任的目录下,workspace 设置被强制为只读。也就是说——你在别人仓库、临时目录、或者没被标记信任的路径下跑 Gemini CLI 时,配置写入行为会被限制。

行动:用了 headless / 脚本化调用的团队,升级后请复核一次「在非信任目录里写配置」的路径。 它和 v0.64.0 的 #29528(headless 下目录信任状态正确传递)是同一件事的两半:先修「信任状态没传下去」,再修「传下去之后真的按它限制」。

长会话:两处「越用越糟」被堵上

PR修复为什么值得单独记
#29618恢复会话时不再产生重复的工具响应轮次续跑一次多一轮工具响应,上下文会越续越胖;token 消耗异常时可以先归因到这里
#29584快速退出不再删掉已恢复会话的历史与 v0.64.0 的崩溃恢复是同一主题的收尾——此前「打开→立刻关掉」可能把刚恢复的历史又删了

放在一起看:v0.64.0 解决了「崩溃时不丢」,v0.65.0 解决了「恢复过程本身不产生新问题」。一次完整的可靠性收尾分成两个版本做,这本身就说明状态管理在 agent CLI 里有多难。

企业接入:OAuth 校验对齐 RFC 9207

#29616 —— fix(core): align OAuth callback iss parameter validation with RFC 9207 metadata。

RFC 9207 是 OAuth 2.0 授权响应的 iss 参数(授权服务器身份标识),用于防止混合部署下的混淆攻击。Gemini CLI 把它对齐到元数据之后,对 IdP 实现合规性的要求变严了。

行动:自建 OAuth / 企业 IdP 接入的团队,升级后请复核登录链路。合规的 IdP 不受影响;实现不规范的可能会出现此前能过、现在过不去的情形。

其余值得一提的条目

PR条目类型
#29476修好交互模式下按回车卡住(issue #23297)fix
#29582优化 ignore 过滤并启用子树剪枝(#29077),大仓库文件发现更快perf
#29672消除不受信任命令标志与复合循环的误报fix
#29643重新选择 Google 登录时清除缓存凭据fix
#29677ask_user 的问题文本保留在工具结果展示里fix
#29720单个扩展未通过 allowlist 校验时不阻断其他扩展加载fix

完整条目列表见文末 Release Notes 原文链接,本站不逐一转录。

对开发者的影响

① 跑生产 / CI 的:钉 v0.65.0。 连续两个 stable 都是修复为主,回归风险低于跨功能版本。

② 用脚本在非信任目录跑的:升级后回归一次写入路径(#29583)。

③ 自建 IdP / OAuth 的:复核登录链路(#29616)。

④ 接了 OTel 的:现在可以带自定义 header 了(#29641),此前因为不能鉴权而放弃接入的团队可以重新评估。

⑤ 长会话用户:这一版解决了「越续越胖」(#29618),值得升。

⑥ 别急着上 v0.66.0-preview.0——它比 stable 早 14 分钟发布,且是下一个功能周期的开端。

AI 之家 观点

连续两个 stable 版本都是「没有新模型、没有新能力」,这件事本身已经是可判断的信号了。 结合本站 10-14 修正后的判据(看 Release Notes 的条目类型,不要看 stable 停滞时长),现在可以更明确地说:Gemini CLI 在 2026 年 10 月这一轮的周期主题是可靠性收尾,不是功能扩张。

换成选型语言:如果你的犹豫是「要不要等下一个大版本」,这两版不构成等待理由;如果你的犹豫是「要不要升级」,这两版都是低风险的正收益。

第二个观察:这一版把「信任」做成了真正生效的边界。 #29583(不受信任目录强制只读)与 #29672(消除不受信任命令标志的误报)是一对——一边收紧,一边减少误伤。只收紧不减误伤会让工具难用,只减误伤不收紧等于没边界。两件事放在同一版做,说明团队清楚这个平衡。

对比 Claude Code 同期在做的「谁批准」(decider: "person"、MCP 同意对话框防误触)与「谁能被看到」(allowedMcpServers 语义调整),两条产品线的收敛方向一致:把 agent 的边界从「靠人守」变成「靠机制守」。选型时看 changelog 的排序,比看 feature 列表更能判断工具未来半年往哪走。

第三个观察要落到本站自己的纪律上。 本站 10-17 写下「v0.65.0-preview.0 未转正」,10-20 它就转正了。这不是判断错误——当时的快照是准确的——但它是「用当前快照暗示未来走向」的典型风险。 延续本站 10-21 形成的写法:被证伪时保留原判断痕迹并追加结案,不静默改写。 工具卡里那处已按此处理(保留 10-17 原句并加删除线 + 失效说明)。

待核实

  • v0.65.0 的厂商公布发布日:published_at 为 2026-10-20T21:17:57Z(GitHub Releases API 一手),但该字段是 tag 发布时间,未必等于官方公告发布日。
  • Gemini 4 Argon 是否已进入 CLI 模型列表:v0.65.0 的 Release Notes 未出现任何模型相关条目;Argon 虽已于 2026-10-13 全球开放(见 发布资讯),本站未核对 CLI 侧模型清单,保持待核实,请勿按「模型发布了 = CLI 能用」推断。
  • #29583 的具体限制面:官方只有 PR 标题,未说明哪些 workspace 设置项会被强制只读,建议自测。
  • #29641 的 header 配置方式:官方未给出配置示例字段名,本站未读配置文档,请以官方文档为准。
  • #29616 对现有 IdP 的兼容性影响范围:官方未列出已知受影响实现,需自测。

来源

相关对比

Aider vs Claude Code:终端 AI 编程双雄怎么选

Aider vs Claude Code 2026 选型对比:开源 BYOK 多模型 vs Anthropic 订阅长任务 Agent,从编程能力、多模型支持、价格、Git 集成、国内可用性和适合人群判断,帮你选对终端 AI 编程工具。

Claude Code vs Cline:CLI AI Agent 怎么选?2026 对比

Claude Code vs Cline 2026 选型对比:Anthropic 官方闭源 CLI Agent vs Apache-2.0 开源 VS Code 插件。从模型绑定、工作流、MCP 支持、价格、隐私和适合人群 6 个维度帮你选对 CLI AI 编程工具。

Claude Code vs Codex CLI:终端 AI Agent 双雄对比

Claude Code vs Codex CLI 2026 选型对比:Anthropic 与 OpenAI 两大官方终端 Agent 的模型、长任务、MCP 生态、Windows 支持、订阅打包价格和国内可用性全方位对比,帮你判断该用哪个终端 AI Agent,以及能不能两个一起用。

Claude Code vs Crush:Anthropic 官方 vs 多模型 TUI(2026 实测选型)

Claude Code vs Crush 怎么选:Anthropic 官方 CLI(长任务最稳),对上 Charmbracelet 开源 TUI(多模型切换 + LSP)。按模型、长任务、价格对比。

Cursor vs Claude Code:什么时候用哪个?(2026 实测选型)

Cursor 和 Claude Code 到底怎么选?一句话结论 + 决策树 + 价格实测 + 国内可用性对比。GUI 派选 Cursor,终端长任务派选 Claude Code,最优解其实是共存。

Devin vs Claude Code:AI 编程 Agent 怎么选?异步自主 vs 终端同步对比

Devin vs Claude Code 2026 选型对比:Cognition 异步自主 Cloud Agent vs Anthropic 终端同步 CLI Agent,从形态、工作模式、长任务能力、并发、价格、中文支持和适合人群 8 个维度判断,帮你选对 AI 编程 Agent。

相关评测