1. 从一次本地审计说起：Claude Desktop 到底往浏览器里写了什么
如果你在 macOS 上装过 Claude Desktop，又恰好用 Chrome、Brave 或 Edge 作为主力浏览器，那么你的电脑里很可能已经躺着几个你从没主动创建过的 JSON 文件。它们藏在NativeMessagingHosts目录下，文件名统一是com.anthropic.claude_browser_extension.json，内容指向 Claude 安装目录里的一个chrome-native-host二进制程序。这就是最近被隐私研究者 Alexander Hanff 公开讨论的 Claude Desktop 写入 Chromium Native Messaging 清单文件的行为。
先把概念说清楚，不然后面复现会一头雾水。Native Messaging 是 Chromium 系浏览器提供的一种扩展与本地程序通信的机制。普通浏览器扩展跑在沙箱里，能碰的东西有限；而通过 Native Messaging 拉起的本地程序运行在浏览器沙箱之外，权限等同于当前登录用户，能读写文件、执行命令。正常流程是：用户先装扩展，扩展请求与本地程序通信，用户点同意，配置文件才被创建。而这次被曝光的点在于，Claude Desktop 在用户没有安装任何 Anthropic 浏览器扩展的情况下，主动向多个 Chromium 浏览器的配置目录写入了清单文件，并且预先授权了三个固定的扩展 ID。
这件事对普通用户意味着什么？简单讲，只要那三个扩展 ID 中的任意一个出现在你的浏览器里，浏览器就会自动允许它调用chrome-native-host，而这个程序具备打开标签页、共享登录态、读取 DOM、执行自动化任务的能力。你不需要点任何“同意”，授权链条在文件写入那一刻就已经铺好了。本文不讨论厂商动机，只做一件事：在本地隔离环境里把这个行为复现出来，看清楚文件路径、清单结构、注册方式，然后把模型调用通道切到 TaoToken 统一 Key，观察请求归属和日志差异，最后给出可复制的排查命令。
适合谁看？三类人。第一类是想搞清楚自己电脑上到底被写了什么的安全敏感用户；第二类是做浏览器扩展或桌面端集成的开发者，需要理解 Native Messaging 清单的注册规则；第三类是已经在用 Claude Desktop 或类似工具、想把模型 endpoint 统一管理起来的工程同学。下面所有操作都在本地可回滚，删文件、改配置都有对应命令，跟着做就行。
需要提前说明的是，本文的复现目的是“观察与验证”，不是教你写后门。所有清单文件都是明文 JSON，路径固定，删掉即可；真正值得关注的是“谁在什么时候、以什么权限、往哪里写了什么”，这才是审计的核心。
2. 复现前的环境准备与 TaoToken 统一 Key 接入
在动手复现之前，先把环境理清楚，否则你会在“这文件到底是谁写的”这个问题上绕圈。我建议用一台干净的 macOS 用户账户，或者至少是一个你愿意折腾的测试账户。浏览器方面，装一个 Chromium 内核的就行，Brave、Chrome、Edge 任选，不用七个全装——原报告里提到 Claude Desktop 会给七个浏览器都写，但复现时一个足够观察机制。
第一步，确认 Claude Desktop 的安装位置和辅助程序。打开终端，执行：
ls -la /Applications/Claude.app/Contents/Helpers/ | grep -i native正常会看到chrome-native-host这个可执行文件。用file看一下它的架构：
file /Applications/Claude.app/Contents/Helpers/chrome-native-host输出里会显示 Mach-O universal binary，说明它是通用二进制。再用codesign看签名主体：
codesign -dv --verbose=4 /Applications/Claude.app/Contents/Helpers/chrome-native-host 2>&1 | grep -E "Authority|TeamIdentifier"这一步是为了确认“这个二进制确实来自 Claude Desktop 的签名链”，而不是某个第三方塞进来的东西。审计的第一原则就是先确认文件来源。
第二步，准备 TaoToken 的接入信息。为什么要在这里引入 TaoToken？因为复现过程中你会希望观察“模型请求到底发到了哪里”。如果 Claude Desktop 或你本地的辅助工具直连官方 endpoint，日志里看到的域名是固定的；而把 endpoint 统一改到 TaoToken 之后，请求归属、Key 使用、调用日志都会集中到一处，方便你对照“浏览器侧行为”和“模型侧行为”是不是同一套触发链路。
TaoToken 的 API 入口是https://taotoken.net/api，控制台和 Key 管理在https://taotoken.net/console，API Keys 页面是https://taotoken.net/api-keys。你需要先拿到一个 Key，然后把它写进本地配置。注意，这里不是让你把 Key 硬编码进浏览器扩展，而是写进你本地辅助程序或 Claude Desktop 的模型配置里。
第三步，建立一个隔离的配置目录，避免污染你日常用的浏览器配置。比如：
mkdir -p ~/audit-lab/native-messaging mkdir -p ~/audit-lab/logs后面所有观察到的清单文件、日志、抓包结果都往这里放。这样即使你误删了什么，也不会影响主环境。
第四步，确认你的浏览器 NativeMessagingHosts 目录在哪。不同浏览器路径不同，macOS 下常见的有：
| 浏览器 | NativeMessagingHosts 路径 |
|---|---|
| Google Chrome | ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/ |
| Brave | ~/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts/ |
| Microsoft Edge | ~/Library/Application Support/Microsoft Edge/NativeMessagingHosts/ |
| Chromium | ~/Library/Application Support/Chromium/NativeMessagingHosts/ |
| Vivaldi | ~/Library/Application Support/Vivaldi/NativeMessagingHosts/ |
| Arc | ~/Library/Application Support/Arc/User Data/NativeMessagingHosts/ |
| Opera | ~/Library/Application Support/com.operasoftware.Opera/NativeMessagingHosts/ |
你可以先用一条命令把所有可能存在的清单文件列出来：
find ~/Library/Application\ Support -name "com.anthropic.claude_browser_extension*" 2>/dev/null如果输出为空，说明当前账户下还没有被写入，或者你已经清理过。如果输出了若干路径，先别急着删，复制一份到~/audit-lab/native-messaging/留档，再继续后面的分析。
环境准备好之后，下一步就是真正去看清单文件的内容和注册机制。这里要提醒一句：复现的目的是理解机制，不是去激活任何扩展。你只需要读文件、看结构、抓请求，不需要真的让某个扩展去调用chrome-native-host。
3. 可复制的 Native Messaging 清单与配置片段
这一节是全文最“硬”的部分，给出可直接复制的清单结构、注册位置和配置片段。先看被曝光的清单文件长什么样。根据公开信息，它的内容大致如下：
{ "name": "com.anthropic.claude_browser_extension", "description": "Claude Browser Extension Native Host", "path": "/Applications/Claude.app/Contents/Helpers/chrome-native-host", "type": "stdio", "allowed_origins": [ "chrome-extension://dihbgbndebgnbjfmelmegjepbnkhlgni/", "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/", "chrome-extension://dngcpimnedloihjnnfngkgjoidhnaolf/" ] }逐字段解释一下，方便你判断风险点在哪。name是 Native Messaging 主机的唯一标识，浏览器扩展通过这个名字去查找本地程序。path指向实际可执行文件，这里是 Claude 安装目录下的chrome-native-host。type为stdio，表示浏览器通过标准输入输出与本地程序通信。allowed_origins是关键：它列出了允许调用这个本地程序的扩展来源，只有列表里的扩展 ID 才能建立连接。也就是说，这三个 ID 就是“预授权名单”。
你可以把上面这段 JSON 保存到~/audit-lab/native-messaging/com.anthropic.claude_browser_extension.json作为样本，但不要直接放进浏览器的 NativeMessagingHosts 目录去激活。观察结构就够了。
接下来看注册位置。macOS 下，Chromium 系浏览器读取 Native Messaging 清单的目录是固定的，就是上一节表格里那些NativeMessagingHosts路径。Claude Desktop 的做法是向每个存在的（甚至不存在的）浏览器配置目录写入同一个 JSON。你可以用下面这条命令模拟“检查所有浏览器是否被写入”：
for d in \ "$HOME/Library/Application Support/Google/Chrome/NativeMessagingHosts" \ "$HOME/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts" \ "$HOME/Library/Application Support/Microsoft Edge/NativeMessagingHosts" \ "$HOME/Library/Application Support/Chromium/NativeMessagingHosts" \ "$HOME/Library/Application Support/Vivaldi/NativeMessagingHosts" \ "$HOME/Library/Application Support/Arc/User Data/NativeMessagingHosts" \ "$HOME/Library/Application Support/com.operasoftware.Opera/NativeMessagingHosts"; do if [ -f "$d/com.anthropic.claude_browser_extension.json" ]; then echo "[FOUND] $d" else echo "[MISS ] $d" fi done这段脚本只读不写，安全。跑完之后你会清楚知道哪些浏览器目录被写入了清单。
再看 Windows 侧的注册方式，因为很多读者是 Windows 环境。Windows 下 Native Messaging 清单不是放在浏览器目录，而是通过注册表指向一个 JSON 文件。注册表路径通常是：
HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension默认值指向清单文件的完整路径。你可以用reg query查看：
reg query "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension" /ve如果存在，会返回一个REG_SZ值，指向类似C:\Users\<你>\AppData\Local\Claude\...\com.anthropic.claude_browser_extension.json的路径。Brave、Edge 的注册表根键分别是HKCU\Software\BraveSoftware\Brave-Browser\NativeMessagingHosts\和HKCU\Software\Microsoft\Edge\NativeMessagingHosts\，结构一致。
现在把模型调用通道切到 TaoToken。假设你本地有一个辅助程序或 Claude Desktop 的模型配置，需要设置三个东西：Base URL、API Key、Model ID。以常见的 OpenAI 兼容配置为例，可以写成这样：
{ "base_url": "https://taotoken.net/api", "api_key": "sk-你的TaoTokenKey", "model": "claude-sonnet-4-20250514" }如果你用的是 Claude Code 或类似的 CLI 工具，配置通常落在~/.claude/settings.json或项目级.claude/settings.json，片段如下：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的TaoTokenKey", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }注意，Base URL 用https://taotoken.net/api，不要带多余路径。Key 从https://taotoken.net/api-keys获取。Model ID 按你实际要用的模型填。这三件套（Base URL + Key + Model ID）是任何接入场景的最小集合，缺一个都会在验证阶段报错。
如果你用的是 Cline、Roo Code 这类 VS Code 扩展，配置界面里同样填这三项，Provider 选 OpenAI Compatible 或 Anthropic Compatible，Base URL 填 TaoToken 的 API 地址。这样做的目的是让所有模型请求都经过同一个通道，方便你在 TaoToken 控制台看到调用日志，和浏览器侧的 Native Messaging 行为做时间线对照。
配置写完之后，先别急着跑浏览器。下一步是发一个最小验证请求，确认通道本身是通的。
4. 验证请求与成功结果：从 curl 到日志对照
配置写完，第一件事是确认 TaoToken 通道能正常返回。用 curl 发一个最小请求：
curl -sS https://taotoken.net/api/v1/messages \ -H "Content-Type: application/json" \ -H "x-api-key: sk-你的TaoTokenKey" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-sonnet-4-20250514", "max_tokens": 64, "messages": [ {"role": "user", "content": "只回复两个字：通了"} ] }'如果返回里包含content字段和类似"text": "通了"的内容，说明 Key、Base URL、Model ID 三件套都正确。如果返回 401，说明 Key 有问题；如果返回 404 或 model not found，说明 Model ID 写错了；如果连接超时，检查网络和 Base URL 是否写成了https://taotoken.net/api而不是别的路径。
通道验证通过后，开始做“浏览器侧行为”和“模型侧请求”的对照。思路是这样的：Native Messaging 本身不直接发模型请求，它是浏览器扩展与本地程序之间的通道。真正发模型请求的是本地程序或扩展背后的服务。所以你要观察的是：当本地程序被触发时，它发出的模型请求是否出现在 TaoToken 的调用日志里。
具体操作分三步。第一步，在 TaoToken 控制台的日志页面记下当前时间戳和请求计数。第二步，在本地触发一次模型调用，比如用上面的 curl 再发一次，或者用你的 CLI 工具发一次。第三步，回到控制台刷新，看是否多了一条记录，记录里的模型、时间、消耗是否对得上。
为了更直观，你可以把 curl 的输出和 TaoToken 日志并排看。下面是一个成功返回的示例结构：
{ "id": "msg_01XyZ...", "type": "message", "role": "assistant", "content": [ {"type": "text", "text": "通了"} ], "model": "claude-sonnet-4-20250514", "stop_reason": "end_turn", "usage": { "input_tokens": 12, "output_tokens": 4 } }看到usage字段就说明计费链路也走通了。这时候你去 TaoToken 控制台，应该能看到对应的 token 消耗记录。这一步的意义在于：你确认了“模型请求确实经过 TaoToken”，后面再观察浏览器侧行为时，就能用日志时间线去判断“某个浏览器动作是否触发了模型调用”。
接下来做 Native Messaging 侧的验证。前面说过，不要真的去激活扩展。但你可以用lsof或fs_usage观察chrome-native-host是否被浏览器拉起。在 macOS 上：
sudo fs_usage -w -f filesys | grep -i "chrome-native-host"这条命令需要 sudo，会实时打印文件系统事件。当你打开浏览器、且清单文件存在、且对应扩展 ID 的扩展被安装时，你可能会看到浏览器去访问chrome-native-host的路径。如果没有任何扩展安装，通常不会触发。这正好验证了“清单文件是休眠的，需要扩展 ID 匹配才会激活”这个机制。
另一个观察点是日志。Claude Desktop 的日志在~/Library/Logs/Claude/下。你可以统计“Native host installation complete”出现的次数：
grep -c "Native host installation complete" ~/Library/Logs/Claude/main.log 2>/dev/null grep -c "Native host installation complete" ~/Library/Logs/Claude/main1.log 2>/dev/null如果数字大于 0，说明 Claude Desktop 确实执行过安装 Native Host 的动作。这个数字和你在文件系统里找到的清单文件数量可以互相印证。
把这几条线索串起来：文件系统里有清单文件 → 日志里有安装记录 → 浏览器进程可能拉起chrome-native-host→ 模型请求出现在 TaoToken 日志。这条链路走通，你就完成了一次完整的本地复现与验证。整个过程不需要安装任何可疑扩展，也不需要真的让后门“生效”。
最后提醒一句：验证完成后，把你复制到~/audit-lab/的样本保留，把浏览器目录里的清单文件按需清理。清理命令在下一节排障里给。
5. 本篇常见报错排查：401、local proxy failed 与 reading choices
复现过程中最容易卡住的不是机制本身，而是各种报错。这一节把常见错误和对应解法列清楚，都是真实会遇到的。
401 Unauthorized。这个最常见，出现在 curl 或 CLI 调用 TaoToken 时。原因通常是 Key 写错、Key 前后有空格、或者用了错误的 Header 名。Anthropic 兼容接口用x-api-key，OpenAI 兼容接口用Authorization: Bearer。如果你把两者搞混，就会 401。检查方法：
echo "sk-你的TaoTokenKey" | wc -c确认长度合理，没有多余换行。然后确认 Header：
curl -sS -o /dev/null -w "%{http_code}\n" https://taotoken.net/api/v1/messages \ -H "x-api-key: sk-你的TaoTokenKey" \ -H "anthropic-version: 2023-06-01" \ -H "Content-Type: application/json" \ -d '{"model":"claude-sonnet-4-20250514","max_tokens":8,"messages":[{"role":"user","content":"hi"}]}'返回 200 就对了，返回 401 就回去查 Key。
local proxy failed。这个报错通常出现在你本地配了代理、但代理没起来或端口不对的时候。注意，这里说的代理是你本地开发用的 HTTP 代理，不是任何网络工具。检查你的环境变量：
env | grep -i proxy如果有HTTP_PROXY或HTTPS_PROXY指向一个没启动的本地端口，就会报 local proxy failed。临时清掉：
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy然后再发请求。如果你确实需要走本地代理做抓包观察，确保代理进程在监听，端口和配置一致。
reading choices 相关报错。这个多见于 OpenAI 兼容接口的响应解析。当你用某个客户端去调 TaoToken，客户端期望返回里有choices数组，但实际返回的是 Anthropic 格式的content数组，就会报类似 “cannot read property choices of undefined” 或 “reading 'choices'” 的错误。解法是确认客户端用的接口协议和你的 Base URL 路径匹配。Anthropic 格式走/v1/messages，OpenAI 格式走/v1/chat/completions。如果你在 Cline 里选了 Anthropic Provider，就不要填 OpenAI 的路径。
OAuth 相关报错。有些工具（比如 Claude Code）默认走 OAuth 登录，而不是 API Key。如果你已经把 Base URL 改到 TaoToken，但仍然走 OAuth 流程，就会报 OAuth 失败或 token 无效。解法是在配置里显式使用 API Key 模式，把ANTHROPIC_API_KEY设好，并确认没有残留的 OAuth token 文件干扰。检查：
ls -la ~/.claude/ 2>/dev/null如果有credentials.json之类的 OAuth 缓存，先备份再移走，强制走 Key 模式。
清单文件删了又回来。这是被曝光行为的一个特征：Claude Desktop 每次启动会重新写入。如果你确认要阻止，只能卸载 Claude Desktop，或者用文件权限手段让目录不可写（不推荐，可能影响浏览器正常功能）。清理命令：
find ~/Library/Application\ Support -name "com.anthropic.claude_browser_extension.json" -print -delete加-print是为了让你看到删了哪些，避免误删。Windows 下对应删除注册表项：
reg delete "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension" /f其他浏览器把根键换掉即可。
TaoToken 返回 404 或 model not found。检查 Model ID 是否拼写正确，以及该模型是否在你的套餐里可用。可以到https://taotoken.net/doc看支持的模型列表。Base URL 确认是https://taotoken.net/api，不要多加/v1之外的路径。
把这几类报错处理完，你的复现链路基本就顺了。剩下的就是按需清理和记录。
6. 把通道统一到 TaoToken：长期编码与 Agent 场景的接入建议
复现做完，清理完清单文件，最后聊一下为什么值得把模型调用通道统一到 TaoToken。这次事件的核心不是“某个二进制有多危险”，而是“授权链条可以在用户不知情的情况下被铺好”。对开发者来说，对应的启示是：你对自己项目里每一条模型请求的归属，应该有清晰的掌控。
如果你在做长期编码、Agent 编排或者多工具混用，模型 endpoint 散落在各个工具里是常态。Claude Desktop 一套、CLI 一套、VS Code 扩展一套，每套都有自己的 Key 和日志。出了问题，你很难判断是哪个环节发起的请求。把 Base URL 统一到https://taotoken.net/api，Key 统一从https://taotoken.net/api-keys管理，日志集中在一处，排查成本会低很多。
具体接入时，记住三件套：Base URL、API Key、Model ID。任何工具，只要支持自定义 endpoint，就填这三项。Claude Code 类工具改settings.json的env段；Cline 类扩展在设置界面填 Provider 和 Base URL；自己写的脚本直接读环境变量。这样无论上层工具怎么换，底层通道是稳定的。
如果你要验证某个模型是否可用，可以用模型对话页面发一条测试消息，确认返回正常再写进配置。如果你在做 Agent 或长期编码任务，建议用 Coding Plan 这类按周期计费的方式，避免按量计费在长任务里失控。
最后回到这次复现本身。你学到的不是“怎么装后门”，而是“怎么审计一个 Native Messaging 清单”：看路径、看allowed_origins、看日志、看进程、看模型请求归属。这套方法可以迁移到任何桌面端与浏览器集成的场景。清单文件是明文的，路径是固定的，日志是可查的——只要你愿意花十分钟去看，就不会对“谁在我电脑上写了什么”一无所知。
