TraeWork 的权限与审批：三套配置参考怎么读

一、这组开关是来处理哪种为难的

让一个智能体在自己的电脑上跑命令，这件事天生是两头堵的。管得松，它可能在你没看清楚的时候删掉一个目录、把某个内网地址请求了一遍；管得严，你就得坐在旁边一条条点确认，跑十分钟的活儿变成陪它坐半小时，这时候人多半会干脆把所有检查一次性关掉——然后回到第一种状态。

TraeWork 把这件事拆成了三个方面，官方文档《权限审批概览》开头就把它们并排列了出来：命令是否在沙箱中隔离执行、是否启用危险命令拦截和文件保护等安全检查、以及需要审批时由谁来决策。第三个问题是最容易被忽略的一个——它跟前两个不是一回事。前两个决定”什么情况会触发审批”，第三个只决定”触发之后谁来点头”。文档在《自定义权限模式配置参考》里特意为 reviewer 字段写了一句话把这层区分挑明：该字段不决定哪些操作需要审批，只决定审批触发后的处理方。读配置的时候把这句话记住，后面那堆字段就不容易串味。

还有一个前置得先摆在前面，因为它直接决定你要不要往下读：文档写明”权限与审批”功能仅作用于 TraeWork 中的本地任务，云端任务皆运行于隔离的云端环境，无需配置权限模式。所以如果你的活儿全在云端跑，这一整套东西跟你无关。

二、官方文档写明它怎么用

先看三种预设模式。文档给的表格是这样三行：

模式	文档写明的行为
手动审批	沙箱开启，命令在隔离环境中执行；危险命令拦截和文件保护已启用，需审批的操作由用户逐一确认
自动审批	沙箱开启，命令在隔离环境中执行；危险命令拦截和文件保护已启用，需审批的操作由 TraeWork 内置的 LLM Guardian 自动判断是否放行
完全访问	沙箱关闭，命令直接在宿主机执行；文件系统完全读写，所有安全检查已禁用，不会触发审批

前两行的差别只在最后半句，也就是上面说的第三个问题：谁来点头。文档另外给了一条提示——开启”自动审批”模式后，若你使用自定义模型，则会由该自定义模型进行审批。这一句值得单独记下来，因为它意味着”自动审批”这四个字背后到底是哪个模型在把关，取决于你自己的模型配置。

第三行则是三个问题一起翻面：沙箱、安全检查、审批全部退场。文档用的措辞是”所有安全检查已禁用，不会触发审批”，没有留任何”但仍会拦截某某”的余地。

设置入口有两处，能力不一样。文档写明在对话输入框处只能为常规任务设置权限模式；要分别为常规任务和自动化任务设置，得走设置 > 权限审批。自动化任务对应的是定时任务，官方《定时任务》一页写明系统会按设定的时间或频率自动执行、“整个过程无需人工干预”——正因为没有人守在旁边，它恰恰是最需要单独定一档的，别只在对话框那一侧改完就以为全设好了。

自定义配置落在一个文件里：~/.trae-cn/permission/global.json。资源授权、规则和自定义权限模式都由这个文件管理。文档同页还带了一条提示：如果使用 Remote SSH 或 WSL 连接到远端设备，需要单独为该设备配置自定义配置，无法复用本机的自定义配置。用 WSL 的人不少，这一行漏读了就会以为配置没生效。

沙箱之外还有默认的资源范围。文档写明在”手动审批”和”自动审批”模式下，TraeWork 会为智能体应用一套内置的文件系统访问范围：根目录 / 是只读，文档给的括注是”所有未显式声明为可写的目录均为只读”；项目目录里除 .trae、.vscode 和 .git 之外的文件与目录可读写，而 .vscode 被单独列为项目目录中的受保护目录、只读。除此之外，各系统的临时目录、通用工具依赖目录（macOS 与 Linux 侧文档列的是 ~/.local/lib、~/.local/bin、~/.local/share，Windows 侧文档写的是 LOCALAPPDATA 环境变量路径内 pip、uv/uvx、npm/pnpm 等常见工具依赖的路径）以及 Go、Java、Python、Node.js、Rust、C++ 等常用语言的工具链目录也在读写范围内。网络这一项文档只有一句：默认允许访问全部网络。

顺带指出文档里的一处写法差异：缓存目录那一行只列了 macOS（~/Library/Caches、~/.cache、XDG_CACHE_HOME）和 Linux（~/.cache、XDG_CACHE_HOME），临时目录那一行则 macOS、Windows、Linux 三个系统都列了。Windows 下的缓存目录是否在默认读写范围内，官方文档没有说明这一点。

三、边界在哪：几处不读到底就会误判的地方

第一处，sceneRules 四个开关的默认值不是你以为的那样。 《自定义权限模式配置参考》给出的默认值表是：

字段	默认值	作用
commandAstDangerChecker	true	命令 AST 静态分析，检测危险命令（文档举的例子是 rm -rf /、chmod 777）并触发审批
shellFileProtection	false	Shell 文件保护（safe_rm），向 Shell 注入安全别名脚本，在终端层面拦截危险的文件删除
deleteToolApproval	false	智能体使用 DeleteFile 工具删除文件时是否需要审批
mcpToolApproval	true	MCP 工具调用默认是否需要审批

两个 false 需要多看一眼。deleteToolApproval 默认 false，文档写明的含义是”直接放行”，理由文档自己给了：文件默认进入回收站，可恢复。也就是说这个默认值成立的前提是回收站兜底，而不是”删文件不重要”。shellFileProtection 默认 false，文档给的定位是”通常在沙箱关闭时作为兜底保护使用”——它跟沙箱是替补关系，你要是把沙箱关了又没打开它，这一层就真的空着。

顺便说一处两页之间的差异：《权限审批概览》里贴出的 global.json 结构示例，sceneRules 中 mcpToolApproval 写的是 false；而《自定义权限模式配置参考》的默认值表里 mcpToolApproval 的默认值写的是 true。两处不一致，以你实际打开的配置文件内容为准。

第二处，优先级是有明确顺序的，别指望”设了就一定生效”。 文档在两页里写了三条优先级：

• customProfiles.defaultCustomProfile.approval.commandRules 的优先级高于 commandAstDangerChecker。一个命令同时命中全局命令调用规则和 AST 危险检测时，以全局命令调用规则为准。换句话说，你在 commandRules 里给某个模式写了 "approval": "allow"，AST 危险检测拦不住它。
• 路径匹配上，路径越长越精确优先级越高；同一路径同时出现在 readWrite 和 readOnly 时，readOnly 优先。网络那边同理：同一地址同时出现在 allow 和 deny 时，deny 优先。
• 资源级配置（resourceAuthorization）优先于自定义权限模式中的默认策略，也优先于系统内置的那套访问权限。

第三处，网络目标授权不是全系统都有。 《自定义全局权限配置参考》在”网络目标授权”这一节顶上挂了一行提示：仅 Windows 和 Linux 支持。文档里那两个示例——把 network.default 设成 deny 再只放行 "*.github.com:443"，或者放行全部再 deny 掉 [10.0.0.0/8]、[172.16.0.0/12]、[192.168.0.0/16] 这几个内网段——照抄之前先确认自己的系统在支持范围里。

第四处，execEnv 的取值说明在文档里是重复的。 commandRules 的策略字段 execEnv 列了三个取值：byConfig 描述为”遵循沙箱配置”，host 描述为”强制在宿主机中执行”，而 sandbox 的描述文字写的也是”强制在宿主机中执行”。两个取值的描述文字相同，文档没有给出 sandbox 与 host 的区别说明。这一点我们没有依据判断实际行为，只能照实指出来。

第五处，写在最后但最要紧的：沙箱不等于安全。 shellSandbox.onRestrict 有一个取值叫 request_escape_host，文档写明它的语义是”申请在宿主机中执行当前命令”——也就是说被沙箱限制住的命令，是有一条经审批后跳到宿主机上执行的通路的。另外两个取值分别是 request_permission_retry_sandbox（申请授权所需资源，授权后在沙箱内重试）和 fail_immediately（直接向模型返回错误，不申请授权也不重试）。至于沙箱本身隔离到什么程度、能挡住哪些逃逸手法，权限审批这三页文档没有说明这一点（沙箱形态由官方文档《沙箱》一页单独讲，且文档写明不同系统、不同模式下的沙箱形态并不一致），我们也不做任何推断。reviewer 还有第三个取值 always_deny，文档写明是触发审批后一律拒绝、不展示确认弹窗；llm 这一档则写明如果 LLM Guardian 拒绝，会回退为用户确认。

TraeWork 仍在快速迭代，官方文档站上挂着以积分为核心的计费模式更新公告，功能口径与计费口径都可能随版本变动，上面这些字段名和默认值请以你手上那一版的官方文档和实际配置文件为准。

四、什么时候值得动它，什么时候别动

值得配的场景大概三类。 一是你要跑自动化任务，也就是没人守在旁边的那种：这时候默认那档全靠 reviewer 决定，always_deny 和 llm 之间怎么选是要提前想清楚的，别等半夜任务卡在确认弹窗上。二是你的机器上有明确不想让它碰的目录，那就往 resourceAuthorization.filesystem.readOnly 里写路径，记住 readOnly 压 readWrite，写重了不会打架。三是团队里有几个高频命令天天要被拦一次，比如文档示例里那种把 git *、npm * 设成 allow 的写法——但这类放行是有代价的，因为 commandRules 会压过 AST 危险检测，模式写得越宽，兜底越薄。

不必动它的场景也很清楚。 你的任务全在云端跑，那这一整套本地权限配置对你不产生作用。你只是偶尔让它读几个文档、改点文字，默认那套内置范围里项目目录已经是可读写的，没必要额外开路径。用 macOS 的话，网络目标授权这一节先不用花时间，文档写明不在支持范围内。

最后一句是通用做法、不是该产品官方文档的内容：把”完全访问”当成常态是一个需要自己评估风险的选择，因为文档明写这一档下所有安全检查已禁用、命令直接在宿主机执行。用不用、在哪台机器上用，得结合你自己那台机器上装着什么来判断。

---

本文依据 TraeWork 官方文档（docs.trae.cn）于 2026-08-17 的公开内容整理。 我们没有开通付费账号，也没有实际操作过该产品，因此不涉及界面外观、操作手感与生成质量的任何描述。 该产品仍在快速迭代，功能与计费口径随版本变动，文中涉及积分与套餐的表述均为复述官方文档原文， 请以官方最新公告与定价页为准。 安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。