Claude Code MCP headersHelper 为何要先信任目录

claude code mcp headersHelper 信任：很多 MCP 服务器要用短时 HTTP 头（Bearer、签名）。headersHelper 负责在本地跑一小段逻辑吐出这些头。2.1.238 起，从项目 .mcp.json、或项目/插件 agent 文件里内联出来的 helper，必须先接受该文件夹的信任对话框（claude -p 同样）；并且这类来源的 helper 不再继承会话里的凭证环境变量。用户级、托管级、claude.ai 作用域、放在 Claude 配置目录里的 helper，行为按原作用域区分。

作者：CodePass 技术编辑

堵住的是哪条路

未信任的仓库若在 .mcp.json 里塞一个 helper，旧路径下有可能摸到你已经 export 进会话的云密钥、代理票、CI token。现在：先弹信任；即便你点了信任，项目来源的 helper 也跑在「无继承凭证环境变量」的隔离里。这是硬化，不是赶时髦。

同版本 marketplace 的 headersHelper 在拉目录/同源归档时会先展示命令再 [y/N]（或 -y）。claude mcp list / get 对已禁用服务器直接显示 Disabled，不再为探活去连。

升级后你会看到什么

• 打开含项目 MCP 的仓，第一次跑 helper 相关能力时多一步信任确认。
• 以前靠「继承环境变量里的 API key」的项目 helper 可能突然拿不到票，需要改成显式注入或改用用户/托管作用域 helper。
• 自动化 claude -p 流水线若假设「无交互也能跑项目 helper」，会在信任门前停住。CI 应用托管 settings 或预信任策略，而不是关安全。

插件与 MCP 选型背景可对照 Skills vs MCP。拦截危险命令的另一类工具见 MCP Interceptor。

推荐落位

来源	适合放什么
用户/托管 Claude 配置目录	公司统一的 mint 脚本、与身份绑定的 helper
项目 .mcp.json	仅项目公有、无密钥的头逻辑；密钥走 vault 侧车
插件	审核过的上游；仍过信任与确认

不要把长期云密钥硬编码进 helper 源码。短时票从旁路服务取，helper 只做组装。

排障

1. 确认版本 ≥ 2.1.238。
2. 看是否尚未接受目录信任。
3. 用 claude mcp list 确认服务器未 Disabled。
4. 若 helper 需要凭证，迁到用户/托管作用域，或改架构让 runner 环境注入非继承通道（按你们安全模型设计）。

本文只描述官方硬化意图与配置后果，不提供绕过信任门的做法。

若你维护内部插件市场，把「headersHelper 是否触及凭证」写进上架检查表：默认假设项目级 helper 零凭证，需要票就走托管配置目录。这样开发者克隆任意开源仓时，不会在第一次 /mcp 时把公司代理票暴露给陌生脚本。