不用外挂，让 CodeBuddy 替你回微信：一条合规链路的九步搭建记录

这篇文章记录的是我自己搭过一遍的完整链路——从装 CLI 到消息回传，九步，每一步都写清装什么、敲什么、报什么错。所有涉及平台规则与接口参数的地方，我标注了来源：企业微信开发者中心的《发送消息》《全局错误码》《违规场景及处罚规则》，微信开放社区的《发送客服消息》，以及 CodeBuddy 官方文档的《Headless Mode》与《CLI Reference》。凡是我在自己机器上跑出来的结果，会明确写"本机实测"。

先说结论：能走通，但能走通的前提是你先接受它的边界。

第一部分：动手之前，先确认这条路能不能走

我先去把三份官方文档读了两遍。不是为了抄参数，是为了搞清楚一件事：哪些做法会被判违规。

企业微信开发者中心的违规场景及处罚规则文档里有一段话，我建议每个准备动手的人先抄在便签上：未经腾讯许可使用插件、外挂或其他第三方工具、服务接入本软件和相关系统。规则给出的例子很具体：外挂多开、批量自动加好友、规避消息群发次数限制；制作、发布、传播上述工具及相关资源与教程，也一并列入。对应的处罚是永久封禁违规成员账号；若违规行为严重或造成恶劣影响，不排除同时封禁企业账号及管理员账号。

这里要分清一套容易混淆的机制。规则里另有一套三级递进的处罚：首次短期禁用互通、再犯不可申请解封、第三次永久禁用。但这套递进针对的是诱导分享、骚扰信息、恶意添加外部联系人那几类行为。外挂行为不在递进里，它直接落在永久封禁这一档，严重时连企业与管理员一并封禁。

注意这里的措辞层级。它不是“接口调用失败”，不是“限流”，而是账号级别的封禁，且处罚对象可以上溯到管理员。这意味着你在做技术选型时，评估的不是“能不能跑通”，而是“跑通之后会不会把整个企业拖下水”。

三条路，只有一条能走

市面上流传的接入方式大致三类，我逐一说明为什么前两条走不通。

客户端注入。往微信或企业微信客户端里注入代码、改内存、挂 Hook，让 AI 直接操作界面。技术上确实可行，但它精确命中了规则里"插件、外挂或其他第三方工具"的定义。而且这类方案天然脆弱：客户端一升级就失效，你还得跟着逆向。收益是省事，代价是账号。

协议模拟。自己实现一套通信协议，伪装成客户端登录。这条路的问题有两层：一是同样属于"未经许可的第三方工具接入"；二是它绕过了平台的风控与审计，一旦被识别，判定往往更重。我在几个技术群里见过有人拿它做私域群发，账号存活周期以周计。

官方客服接口。企业微信提供了微信客服能力，有完整的接收消息回调、读取消息、发送消息接口，有文档、有错误码、有权限体系。它慢，它有限制，但它是唯一一条"平台希望你这么用"的路。

我选第三条。不是因为道德感，是因为只有这条路的失败模式是可预期的——你会收到 errcode，而不是收到封号通知。

规则反推产品形态

选定接口之后，第一件事不是写代码，是读限制条款。

《发送消息》接口的原文是：仅当微信客户在主动发送消息给客服后的 48 小时内，企业可发送消息给客户，最多 5 条；若用户继续发送消息，企业可再次下发。

这句话直接决定了产品形态。你不能主动追单。用户不说话，你就没有发送窗口；用户说了五句你回了五条，第六条就得等人再开口。任何"AI 主动关怀""定时回访"的设计，在这条规则下都不成立。

我把这个约束写进了需求文档的第一行：这是一个被动响应系统，不是营销触达系统。想清楚这一点，后面所有的架构选择都会顺很多。

四通道额度对照

企业微信体系里能发消息的通道不止一条，额度差异很大。我整理了一张表，选型时对着看：

（来源：企业微信开发者中心《发送消息》、微信开放社区《发送客服消息》）

这张表里有四个容易被忽略的细节。第一，订阅消息不能做多轮对话：一次性订阅是一次授权对应一条消息，发完即止，虽然不限下发时间，但长期订阅只对政务民生、医疗、交通、金融、教育等线下公共服务类目开放，普通电商拿不到；而且长期订阅除类目限制外，还要求长期订阅模板库中存在对应模板，没有模板即便类目相符也调用不了，这一点比类目更容易卡住人。第二，自建应用消息的额度看着大，但它是发给内部成员的，不是发给微信客户的，两者不能混用。第三，还要纠一个偏：订阅消息早已不是模板消息，网上流传的“7 天内必须下发”是模板消息的旧规则，小程序模板消息在 2020 年初就已下线，别把两套机制混着用。第四，额度会变：公众号客服消息在用户发消息场景下，2021 年 6 月至 2023 年 6 月之间是 20 条/48 小时，之后回收至 5 条/48 小时；点击菜单、关注、扫码三个场景的 3 条/1 分钟始终未变。

所以如果你的场景是"微信用户来找客服，AI 接住并回复"，答案只有一个：微信客服接口。剩下的八步，都是围绕它展开的。

第二部分：第 0–2 步，把 CodeBuddy 装上并跑通一条命令

在碰企业微信之前，我先把 AI 这一侧跑通。理由很简单：如果 CLI 都调不通，后面接回调只会让你同时面对两个未知数。

第 0 步：环境清单，别跳过

官方安装文档里列的要求不长，但每一条都有人栽过：

• Node.js 18.20 及以上（部分 MCP 服务器依赖，npm 建议 8 以上）
• Git（版本控制，非必需）
• 终端需支持 UTF-8 编码
• 系统为 macOS / Linux / Windows，其中 Windows 建议走 WSL2

官方只给了 Node 与 npm 的下限，系统版本没有硬性清单，别被网上流传的版本表带偏。

Windows 那一条我要多说一句。原生 PowerShell 能装能跑，但一旦涉及 shell 脚本、路径分隔符、编码，问题会成倍出现。WSL2 不是可选项，是省时间的选项。

第 1 步：安装与验证

三条路选一条，装出来的东西一样，排障路径完全不同。

# 方式一：npm 全局安装（需 Node）
npm install -g @tencent-ai/codebuddy-code

# 方式二：Homebrew（macOS 与 Linux，不需要 Node）
brew install Tencent-CodeBuddy/tap/codebuddy-code

# 方式三：原生安装器（单可执行文件，官方标注 Beta）
curl -fsSL https://www.codebuddy.cn/cli/install.sh | bash

# 统一验证
codebuddy --version

第二条命令必须回出版本号。报 command not found 时，先 which codebuddy 看它实际装到哪，再决定往 PATH 里加什么——三条路径落点不一样，照抄别人的路径常常指到一个空目录。node 缺失时的表现是 npm 直接报错，而不是找不到 codebuddy，两者别混。

安装脚本按平台分两个：macOS 与 Linux 是 https://www.codebuddy.cn/cli/install.sh，Windows 是 https://www.codebuddy.cn/cli/install.ps1，地址以官网安装页当前给出的为准。

脚本与手动二进制通常落在用户目录，PATH 没带上就会出现装完了却用不了：

export PATH="$HOME/.local/bin:$PATH"

Windows 对应位置是 %USERPROFILE%\AppData\Local\codebuddy\bin。

macOS 上建议用 nvm 装 Node，直接下载安装包，后面全局安装大概率撞权限问题。

第 2 步：凭证，三选一，外加一个必设的环境变量

无头模式不继承交互式登录态，这是后面所有授权的起点。

中国版部署必须同时设 CODEBUDDY_INTERNET_ENVIRONMENT=internal（iOA 版设为 ioa），不设就走默认海外环境，这是国内读者最容易卡住、也最难自查的一步；只调模型，API Key 够用，需要 token 刷新与计费查询这类平台能力才用 CODEBUDDY_AUTH_TOKEN。

我第一次部署就栽在这。本机扫码授权过，代码跑得好好的；搬到服务器上用 -p 无头调用，直接返回未授权。原因是交互式登录把凭证写在用户目录的会话文件里，而无头进程读的是另一套。凭证与配置落在用户目录的 ~/.codebuddy 下，换了用户、换了 HOME，读的就是另一份配置，排查时先 echo $HOME，再看那个目录在不在；手动配置密钥可以用 codebuddy config set api-key，写的是同一份配置。更关键的是登录本身的形态——国内走微信扫码，海外走 GitHub 或 Google，服务器上既没有浏览器也没有取景框，这条路在无头环境里其实走不通。因此"先在那台机器上完成一次授权"这句话，落到容器里等于"直接用 API Key"。

还有一个周期性坑：token 到期后会以完全相同的方式失败。不是报"过期"，是报未授权。所以你的监控不能只看"有没有报错"，得看"授权是否还有效"。

最小可运行示例

codebuddy -p "把这条用户消息分类并给出回复草稿" \
--output-format json \
--append-system-prompt "你是电商客服，只回答订单与物流问题" \
--allowedTools "Read" \
--mcp-config ./mcp.json \
--dangerously-skip-permissions

在无头服务里，这个参数常常绕不开。-p 模式下，任何需要授权的工具调用——读文件、发网络请求——都会被权限检查拦下，而报错信息不会告诉你是权限问题。

官方立场比多数教程写得更严：默认情况下，写文件、执行命令、调用 MCP 工具都会请求权限，官方建议用 /permissions 建立命令白名单、用 /sandbox 启用系统级隔离；--dangerously-skip-permissions 会跳过全部检查，一旦遇到提示注入，数据可能直接外泄，官方明确限定它只应在没有网络的沙箱环境中使用。

可接受的边界不是开或不开，而是用多大代价换自动化：网络出口受控、提示词与任务固定、不接触客户手机号与订单明细，三者缺一则宁可改用白名单逐一放行；若场景需要接收用户自由输入，这个开关就不该打开。

几个参数值得单独说：

• -p 是无头模式的入口，一次性执行后退出。
• --output-format 取 text / json / stream-json 三档，结构化输出用 json，流式解析用 stream-json，别用默认的富文本，它与 --input-format、--fallback-model、--append-system-prompt 一样只在 -p 下生效。
• --append-system-prompt 追加系统提示词，仅与 -p 配合生效。
• -c / --resume 多轮对话二选一，前者续最近一次会话，后者按 sessionId 指定恢复。
• --allowedTools / --disallowedTools 限定工具面，生产环境建议用白名单。
• --mcp-config 挂载 MCP 服务器。

我卡住的三个报错

EADDRINUSE。端口被占。多半是上一次进程没退干净，lsof -i :端口 找到 PID 杀掉，或者换个端口。

PowerShell 拒绝执行 shell 脚本。执行策略问题，Set-ExecutionPolicy -Scope CurrentUser RemoteSigned 能解，但我更推荐直接进 WSL2。

未登录拒绝执行。就是上面说的无头模式不继承登录态，先授权一次。

这三个报错加起来花了我整整一个下午。写在这里，是希望你别重复。

第三部分：第 3–5 步，企业微信后台的四个配置动作

AI 侧跑通之后，转到企业微信后台。这一段没有代码，全是点鼠标，但点错一个顺序，后面全白干。

第 3 步：建自建应用，拿五个参数

路径是：企业微信管理后台 → 应用管理 → 创建应用。建完之后，你要凑齐五个参数：

Secret 那一条值得提醒：它不显示在网页上，而是发到管理员的企业微信里。我第一次找它找了十分钟，以为页面加载失败。

两套凭证，别配错。 自 2023 年 12 月 1 日 0 点起，企业微信不再支持通过“系统应用 secret”调用微信客服接口。自建应用要用自己的 Secret 去调 /cgi-bin/kf/sync_msg 与 /cgi-bin/kf/send_msg，前提是把它配置到「微信客服 → 可调用接口的应用」列表里；漏了这一步，报的是权限不足，而不是凭证类型错。另一条线是后台「微信客服 → 开发配置 → API」那套凭证，对应微信客服的独立版形态，联合版与独立版搞混，撞的是 95011 与 95012。95011 的含义是“已在企业微信使用微信客服”，即当前处于联合版，而 access_token 是用独立版 secret 换来的；95012 反之，“未在企业微信使用微信客服”，即当前处于独立版，token 却来自联合版 secret。排查顺序可以这样走：先把应用挂进可调用列表，再确认企业用的是联合版还是独立版，最后才去查签名。

这里有个关键决策：为微信客服单独建一个自建应用。 不要复用已有的应用。原因是回调地址是应用级的，一个应用只能配一个接收消息 URL。如果你已经有别的应用在跑回调，复用会导致两个通道争抢同一个地址，表现为消息时有时无，极难排查。单独建应用解决的是回调地址唯一性的问题，凭证混用的问题要在微信客服的 API 配置里单独解决，两件事不要混为一谈。

第 4 步：配置 API 接收，顺序是坑

URL 的格式是固定的：

协议://域名或IP:端口/路径

例如 https://wecom.example.com/wxkf 或 http://123.45.67.89:9888/wxkf。路径要和你的服务端路由一致，端口要和监听端口一致。

顺序坑在这里：必须先启动服务，再回后台点保存。

企业微信在你点保存的瞬间，会向这个 URL 发一个 GET 请求做验证。服务没起，验证必然失败，页面报"回调地址验证失败"。我在这里卡了整整一个下午，反复检查签名算法，最后发现是服务压根没启动。

正确的顺序是：写好验签服务 → 启动并确认端口可访问 → 回后台填 URL/Token/EncodingAESKey → 点保存。

第 5 步：可信 IP 与端口放行

调试阶段没有公网 IP，用内网穿透。ngrok 或 frp 都行，把本地端口映射出去，拿到一个临时域名，填进回调 URL。

但内网穿透只用于调试验签。原因有两个：一是临时域名会变，二是穿透链路本身不稳定，生产环境的消息回调不能依赖它。

验证通过之后，把可信 IP 换成真实的固定公网 IP。企业微信后台的「企业可信IP」配置项，只有列表里的 IP 才能调用接口。这里有个后续维护点：IP 变更要回来重改。如果你用的是动态 IP 或 DDNS，每次变动都得回后台更新，否则接口调用会被拒。

端口方面，云服务器的安全组要放行你监听的端口。我用的 9888，日志里出现 Listening on http://0.0.0.0:9888/wxkf 才算真正跑起来。

绑定客服账号

最后一步是绑定。进入企业微信后台「微信客服」页面，创建一个客服账号，把它与第 3 步建的自建应用绑定。第 7、9 步调接口用的 Secret，来自第 3 步那个自建应用，前提是它已经挂进「可调用接口的应用」；后台「微信客服 → 开发配置 → API」另有一套凭证，对应独立版形态，两种形态不要混用。

这个链接就是客户入口。用户点进来，发消息，消息才会通过回调推给你。没有这一步，你的服务收不到任何东西——因为微信客服的消息是按客服账号路由的，不是按应用。

到这里，后台配置结束。接下来是真正的代码部分。

第四部分：第 6–9 步，把消息接进来、把回复送出去

这是全文的核心。前五步都是准备，这四步决定系统能不能真的跑起来。

第 6 步：验签解密，一个字节都不能错

企业微信保存回调配置时，会向你的 URL 发一个 GET 请求，带四个参数：msg_signature、timestamp、nonce、echostr。你要做三件事：验签、解密、原样回显。

验签：把 token、timestamp、nonce、echostr 四个参数一起按字典序排序后拼接，做 SHA1，与 msg_signature 比对。注意是 SHA1，不是 MD5，且排序时少 echostr 这一项，服务起得再好也会一直报"回调地址验证失败"。

解密：AES 密钥是 EncodingAESKey 补一个 = 后做 Base64 解码。算法是 AES-256-CBC，IV 取密钥前 16 字节。解密后去掉 PKCS7 填充，企业微信的 PKCS7 填充分组是 32 字节而非常见的 16 字节。明文结构为：16 字节随机串 + 4 字节消息长度（大端序） + 消息体 + receiveid。

回显：返回的是解密后的明文，必须原样返回，多一个空格都过不了。

import hashlib, base64
from Crypto.Cipher import AES

# 1. 字典序排序 + SHA1（注意包含 echostr）
arr = sorted([token, timestamp, nonce, echostr])
sha1 = hashlib.sha1("".join(arr).encode("utf-8")).hexdigest()
assert sha1 == msg_signature, "signature mismatch"

# 2. AES-256-CBC 解密（密钥补等号后 Base64 解码）
key = base64.b64decode(aes_key_b64 + "=")
cipher = AES.new(key, AES.MODE_CBC, key[:16])
decrypted = cipher.decrypt(base64.b64decode(echostr))

# 3. 去 PKCS7 填充（企业微信分组为 32 字节）
pad = decrypted[-1]
content = decrypted[:-pad]

# 4. 跳过 16 字节随机串，读长度，解出明文
body = content[16:]
msg_len = int.from_bytes(body[:4], "big")
plain = body[4:4 + msg_len].decode("utf-8")

这段代码本机实测通过。最容易错的三处：排序时漏掉 echostr、密钥没补等号、忘了跳过 16 字节随机串。

第 7 步：拉取消息，sync_msg 的四个参数

回调只告诉你"有新消息"，具体内容要主动拉。接口是 POST /cgi-bin/kf/sync_msg。

三个硬约束要记住：只能取最近 3 天消息；媒体大小限制为图片 2MB、语音 2MB、视频 10MB、文件 20MB，超出会收到文本提示；不支持读取自己通过发送接口发出的消息。

拉取要写成循环：while has_more: cursor = next_cursor; 再请求。别指望一次拿全。

第 8 步：生成回复，双通道与降级

回复生成我做了双通道。

CodeBuddy CLI 通道：负责需要工具、MCP、知识库检索的复杂请求。用 --mcp-config 挂知识库，用 --resume 续会话保持上下文。

模型 API 直连通道：负责高频短回复，比如"在的""稍等""已为您查询"。这类请求走 CLI 太重，延迟高。

降级策略：CLI 超时或失败，自动降级到 API 直连。提示词模板分三层——系统层定角色与边界，会话层带历史，任务层给当前消息。系统层里我明确写了"只回答订单与物流，其余转人工"，这条比任何模型调优都管用。

第 9 步：回传发送，四道闸门

发送接口是 POST /cgi-bin/kf/send_msg，参数：touser、open_kfid、msgid、msgtype、text.content。

调用前先确认会话落在「新接入待处理」或「由智能助手接待」这两个节点上。用户主动发消息后 48 小时内最多 5 条。接口返回成功不等于送达，必须监听失败事件回调。这条 5 条额度容易被误判，下面把两条通道分开说。

日常回复走 send_msg，算在 5 条里。欢迎语、排队提示、非工作时间或超时提示、结束语与满意度评价邀请，走的是事件响应消息，用回调给的 code 发送，各自只有 1 条，code 有效期是 20 秒或 48 小时。因此把两条通道混着数，本地预算会一边误拦一边漏拦。另外，会话被转接过的话，转接前已用的条数会继承过来——这一点是实践中总结的，文档没有明说。

第一道闸门：access_token 集中缓存。 /cgi-bin/gettoken 有效期 7200 秒。必须服务端集中缓存，比如 Redis 设 7000 秒或提前 300 秒过期。多实例不可各拿各的，否则互相顶掉、触发限流。

错误码要分清。access_token 超时是 42001，不合法是 40014，这两个才是 token 失效；40001 是 secret 本身不合法，与 token 是否过期无关。95001 是发送次数超限（5 条），95002 是时间超限（48 小时），与 token 状态无关；95011/95012 是版本与 secret 不匹配；95018 是当前会话状态不允许发送或已超 48 小时。

因此排查顺序应当是：先 42001/40014 判 token，再 40001 判 secret，再 95001/95002/95018 判额度时限与会话状态，最后 95011/95012 判版本。

第二道闸门：本地预算拦截。 维护每会话的 {window_start, count}，发送前判 count < 5，超额直接转人工。不等平台报错——平台报错时消息已经丢了，本地拦截才能保住体验。

第三道闸门：三层幂等。 接收层用平台 msgid 去重；处理层用 msgid + stage 防重复生成；发送层用自生成 msgid。这里必须写清前提：官方要求 msgid 在客服账号内唯一，重复提交会被接口拒绝，且该参数长度不超过 32 字节，字符集限于字母、数字、下划线与连字符。但去重的可靠性来自本地发送记录，不是平台兜底——平台只保证"重复的会被拒"，不保证"你一定能收到拒绝的明确信号"。

第四道闸门：失败补偿队列。 发送失败事件进队列，人工或定时重试。

最小链路骨架

回调 → 验签解密 → 入队(msgid去重)
     → sync_msg 拉取 → 生成回复(双通道)
     → 预算检查 → send_msg(msgid幂等)
     → 监听失败事件 → 补偿队列

日志观测点至少四个：回调到达、解密成功、生成耗时、发送结果。缺一个，出问题时你就是在盲猜。

第五部分：上线前那张检查表，以及它挡不住的东西

代码跑通和可以上线，中间隔着一段距离。我给自己列了一张八项自检表，逐条打勾才敢放流量。

只用官方接口，无任何客户端注入或协议模拟

本地 48h×5 条预算拦截已生效，超额转人工

三层幂等落地，发送记录落库

密钥只从环境变量读，仓库里搜不到明文

access_token 集中缓存，多实例共用一份

失败事件补偿队列已接入监控

可信 IP 已换成固定公网 IP，变更流程有记录

日志四个观测点齐全，可回溯单条消息全链路

这张表里，前四项是合规底线，后四项是工程底线。任何一项没打勾，都不该放真实用户进来。

灰度节奏

我的做法是单客服账号 + 1% 流量，观察一周。

一周里重点看三件事：失败事件的比例、转人工的触发频率、以及有没有出现"接口成功但用户没收到"的案例。第三项最难查，因为它不报错，只能靠用户反馈和失败事件回调交叉比对。

检查表挡不住的东西，往往来自外部。比如2026 年 10 月 24 日凌晨，安克、耐克、盒马、CATLINK 等品牌的企业微信账号几乎同时向客户推送**引流链接，卡片文案高度雷同，而这些品牌分属不同行业、彼此并无关联。企业微信安全团队当天回应称，经排查确认为某第三方外挂软件服务被攻破，已将受影响账号强制下线并封禁相关引流链接，同日发布《关于坚决、持续打击外挂软件的公告》，表示将持续排查清理篡改客户端、绕过平台安全机制等外挂行为。

一周之后如果这三项都稳定，再逐步放开账号数和流量比例。别一次性全量，微信客服的会话状态流转有它自己的脾气，量小的时候看不出来。

它挡不住的东西

检查表能挡住代码错误，挡不住规则变化。我搭这套东西的过程中，最大的感受不是技术难，而是边界在动。48 小时、5 条、3 天窗口、媒体大小限制，这些数字今天写在文档里，明天可能就改。比如公众号客服消息在用户发消息场景下曾是 20 条/48 小时，2023 年 6 月起回收至 5 条，接口没变、文档改了，当年按 20 条设计的预算表全部作废。会话状态的判定逻辑、错误码的含义、可信 IP 的校验方式，也都在缓慢演进。所以自动化真正的持续成本，不在写代码，而在边界维护。你得定期回去读文档，得盯着失败事件的分布有没有异常漂移，得在规则更新时重新评估产品形态还成不成立。这套系统不是一个交付物，是一个需要照看的东西。

我想起一个不太恰当但很贴切的比喻。希腊神话里，塞壬的歌声美得让人无法抗拒，奥德修斯把自己绑在桅杆上才听了过去。这条合规链路就是那根桅杆——它不让你唱得更好听，它只是让你在歌声里不至于把船开进礁石。

平台给的接口，本质上是一份被允许的自由。你能在里面做很多事，但你不能假装桅杆不存在。

——END——

参考资料

参考资料

1. 企业微信开发者中心《发送消息》：/cgi-bin/kf/send_msg 接口说明、会话状态前提、48 小时 5 条限制，以及事件响应消息独立额度（欢迎语、排队提示、结束语、满意度评价各 1 条，code 20 秒或 48 小时有效）
2. 企业微信开发者中心《读取消息》：/cgi-bin/kf/sync_msg 参数、3 天窗口、媒体大小限制
3. 企业微信开发者中心《全局错误码》：42001 表示 access_token 超时、40014 表示 access_token 不合法；40001、95001、95002 等错误码含义；95011/95012 表示联合版与独立版 secret 不匹配
4. 企业微信开发者中心违规场景及处罚规则文档：外挂类行为处罚条款
5. 企业微信开发者中心的获取 access_token 文档：/cgi-bin/gettoken、7200 秒有效期；自建应用须配置到「微信客服-可调用接口的应用」
6. 微信开放社区《发送客服消息》：小程序/公众号客服消息额度对照
7. CodeBuddy 官方文档《Headless Mode》：无头模式、-p、--output-format（取 text / json / stream-json 三档，只在 -p 下生效）、--append-system-prompt
8. CodeBuddy 官方文档《CLI Reference》：-c（续最近一次会话）、--resume、--allowedTools、--disallowedTools、--mcp-config、--dangerously-skip-permissions