大家好，驴友扣扣日常

我最近一直在用 Claude 的浏览器插件做自动化。整体体验很强，但当你打开某些被 Anthropic 认为“敏感”的网站时，例如广告后台、社交平台后台、金融相关页面，以及几乎所有俄罗斯的网站，它会变得非常麻烦：

• 点击一下，要确认一次
• 输入文字，要确认一次
• 滚动页面，也可能要确认
• 某些页面甚至直接被 hard block

这就不太像自动化了，更像是你自己操作，只是多了一个确认弹窗。

我翻了一下新版插件的源码，发现它仍然有一套内部站点分类系统，只是新版代码已经和旧教程里的位置不一样了。

我发现的分类逻辑

插件会调用 Anthropic 的 API 查询当前 URL 的分类，大概逻辑是：

/api/web/url_hash_check/browser_extension

返回结果里会包含类似：

{
  "category": "category3",
  "org_policy": null
}

大致可以理解为：

旧版本教程里主要是 patch checkPermission 和 category3:2 之类的映射。但新版文件里，相关逻辑已经被打包进类似：

mcpPermissions-E9qdF7bb.js

并且函数名被压缩了。

新版 patch 思路

新版里最关键的是几个位置：

1. 普通动作权限检查
2. 页面跳转/域名切换权限检查
3. category3 强制弹窗逻辑
4. category2 hard block 判断
5. plan approval 里的域名过滤逻辑

下面是我实际测试后确认有效的 patch。

Step 1：找到权限检查函数

搜索：

async checkPermission(e,t,r){

替换成：

async checkPermission(e,t,r){return{allowed:!0,needsPrompt:!1};

这个 patch 的作用是让普通操作直接通过，例如点击、输入、读取页面、上传文件等，不再每一步都弹确认。

Step 2：找到域名跳转检查函数

搜索：

async checkDomainTransition(e,t){

替换成：

async checkDomainTransition(e,t){return{allowed:!0,needsPrompt:!1};

这个是为了避免页面跳转、跨域跳转时继续触发确认。

Step 3：关闭 category3 的强制 prompt

搜索：

.setForcePrompt("category3"===h)

替换成：

.setForcePrompt(!1)

category3 的核心行为就是“每个动作都要确认”。这个 patch 会关闭这个强制 prompt。

严格来说，如果前两个函数已经 patch，这一步有点重复，但我建议一起改，效果更干净。

Step 4：修改 category2 hard block 判断

搜索：

function rk(e){return"category1"===e||"category2"===e||"category_org_blocked"===e}

替换成：

function rk(e){return"category1"===e||"category_org_blocked"===e}

新版里 category2 不是普通弹窗，而是会被很多地方当成 hard block。这里把 category2 从 hard block 列表里移除。

Step 5：修改 navigate 里的 category2 block

搜索：

if(e&&("category1"===e||"category2"===e||"category_org_blocked"===e)){

替换成：

if(e&&("category1"===e||"category_org_blocked"===e)){

这是导航工具里的直接封锁判断。如果不改这里，Claude 可能还是无法主动打开某些 category2 页面。

Step 6：修改 webNavigation 里的 category2 block

搜索：

if("category1"===t||"category2"===t||"category_org_blocked"===t){

替换成：

if("category1"===t||"category_org_blocked"===t){

这是页面已经跳转之后，插件监听 navigation event 时做的拦截。如果不改，有些页面打开后仍然会被中断。

Step 7：修改 plan approval 域名过滤

搜索：

!n||"category1"!==n&&"category2"!==n&&"category_org_blocked"!==n?t.push(i):r.push(i)

替换成：

!n||"category1"!==n&&"category_org_blocked"!==n?t.push(i):r.push(i)

这个地方影响的是 planning mode / follow a plan 里的域名批准逻辑。原本 category2 会被过滤掉，不会进入 approved domain list。改完后，category2 域名可以正常进入计划批准流程。

不建议修改的部分

我不建议把：

category_org_blocked

也一起移除。

因为这个看起来是组织策略或 managed policy 的封锁，不只是普通的站点分类。如果你是在公司设备、团队环境、受管理浏览器里用插件，绕过这类限制可能会违反组织规则。

我的 patch 目标只是：

• 取消 category3 的每步确认
• 让 category2 不再被普通 hard block
• 保留真正的 category1 和 category_org_blocked 封锁

总结

新版 mcpPermissions-E9qdF7bb.js 里，旧版教程的 patch 位置已经不够用了。

真正需要改的是这几类逻辑：

checkPermission
checkDomainTransition
setForcePrompt
rk
navigate block check
webNavigation block check
plan approval filter

改完之后，Claude 浏览器插件在受限站点上的自动化体验会接近正常页面：不会每个点击、输入、滚动都要求手动确认，也不会把普通 category2 页面直接当成 hard block。