夜雨聆风大家好，驴友扣扣日常
我最近一直在用 Claude 的浏览器插件做自动化。整体体验很强，但当你打开某些被 Anthropic 认为“敏感”的网站时，例如广告后台、社交平台后台、金融相关页面，以及几乎所有俄罗斯的网站，它会变得非常麻烦：
点击一下，要确认一次 输入文字，要确认一次 滚动页面，也可能要确认 某些页面甚至直接被 hard block
这就不太像自动化了，更像是你自己操作，只是多了一个确认弹窗。
我翻了一下新版插件的源码，发现它仍然有一套内部站点分类系统，只是新版代码已经和旧教程里的位置不一样了。
我发现的分类逻辑
插件会调用 Anthropic 的 API 查询当前 URL 的分类，大概逻辑是：
/api/web/url_hash_check/browser_extension
返回结果里会包含类似：
{
"category": "category3",
"org_policy": null
}
大致可以理解为：
| 分类 | 行为 |
|---|---|
category0 | 基本可信，Claude 可以自由操作 |
category3 | 受限，每个动作都容易触发确认 |
category2 | 更严格，很多地方会被当成 hard block |
category_org_blocked | 组织策略封锁，不建议 patch |
category1 | 硬封锁，不建议 patch |
旧版本教程里主要是 patch checkPermission 和 category3:2 之类的映射。但新版文件里，相关逻辑已经被打包进类似：
mcpPermissions-E9qdF7bb.js
并且函数名被压缩了。
新版 patch 思路
新版里最关键的是几个位置：
普通动作权限检查 页面跳转/域名切换权限检查 category3强制弹窗逻辑category2hard block 判断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。
