Open Interpreter 执行策略execpolicy实战基于规则把命令分类为安全、风险与阻止【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本篇技术指南围绕 Open Interpreter 的 Execution policy执行策略展开它是叠加在沙箱之下的规则层会在每一条命令真正执行前完成一次体检并把命令标记为safe/unsafe/forbid。读完本文你将掌握如何在config.toml中编写规则、理解它与审批approval流程的衔接方式并能借助仓库自带的引擎与execpolicy check命令验证每一条规则是否真正按预期工作。执行策略沙箱之下的第一道规则层Execution policy 位于沙箱sandbox之下是代理执行命令前的第一道过滤。它不像沙箱那样从操作系统层面约束进程能力而是直接看这条命令本身在命令运行之前检查其内容并打上标签。打标结果决定这条命令后续走哪条路径——直接放行、交由审批还是一律拒绝。Open Interpreter 为每条命令分配三类标签标签含义safe常规、低风险。无需提示直接通过。unsafe可能改变系统状态。需要审批。forbid始终阻止。Open Interpreter 随附一套合理的默认策略大多数用户从不编辑它。只有当你想获得更严格的控制或运行在共享系统shared system上时才需要阅读本文并自定义规则。策略存放位置config.toml 与规则评估顺序策略从config.toml加载。每一条规则由两部分构成一个匹配命令的模式pattern以及一个动作action。规则以 TOML 数组的形式写在[[execpolicy.rules]]小节下[[execpolicy.rules]] match ls action safe [[execpolicy.rules]] match rm * action unsafe [[execpolicy.rules]] match rm -rf / action forbid评估时有一个极其关键、也是最容易踩坑的语义规则从上到下逐条评估第一条命中的规则生效The first match wins。这意味着把match rm -rf /写在其父模式rm *之后是安全的——因为rm -rf /本身就是rm *的子集匹配从上到下先命中通用规则则后面的forbid永不生效想让特例覆盖通例必须把更具体的规则放在更靠前的位置模式使用类 shell 的通配符shell-style globs例如rm *中的*、pnpm test*中的*都属于这类通配符匹配。三档标签与审批模式的交互方式执行策略是代理的第一道过滤。策略对命令打标之后forbid直接阻止命令完全不进入后续环节safe在不提示without prompting的情况下直接运行unsafe交由你的审批模式approval mode处理参见沙箱与审批。由此可以推出两条非常实用的性质一条safe规则可以显著减少你一天中弹出的审批次数——你信任的命令例如测试、lint不再打扰你一条forbid规则则提供兜底保证即使你在审批提示中意外按下y该命令也永远不会执行。forbid的拦截发生在审批之前审批根本不会有机会放行它。从仓库中新一代执行策略引擎的源码可以印证这套语义核心决策类型Decision定义在 codex-rs/execpolicy/src/decision.rs包含三档Allow无需进一步审批即可运行Prompt请求用户明确批准当以approval_policy never永不批准模式运行时会被直接拒绝Forbidden不做任何考虑直接阻止。可以推断本文面向的config.toml三档标签safe/unsafe/forbid与上述三档决策在语义上一一对应safe≈allow免审批放行、unsafe≈prompt交由审批、forbid≈forbidden无条件拦截。此外当一条命令同时命中多条规则时引擎会取最严格的严重级别作为最终决策forbiddenpromptallow也就是说只要有任何一条规则把它判为forbidden命令就不会执行。常见模式直接可复用的规则片段让你信任的 lint 与 test 命令完全不触发提示把代理会反复执行、且你完全信任的命令标记为safe可以让日常工作流中的干扰降到最低[[execpolicy.rules]] match pnpm test* action safe [[execpolicy.rules]] match pnpm lint* action safepnpm test*这类前缀模式能同时覆盖pnpm test、pnpm test --run、pnpm test:watch等各种变体。对所有破坏性操作强制确认对可能改变远端状态或造成不可逆后果的命令用unsafe强制人工确认用forbid直接封死[[execpolicy.rules]] match git push --force* action unsafe [[execpolicy.rules]] match drop database* action forbiddrop database这类操作即便是开发库也几乎不该由代理自动执行因此用forbid而不是unsafe是更稳妥的默认选择——毕竟unsafe只代表需要审批而审批仍可能被人为放行。验证规则execpolicy check 命令模式采用类 shell 通配符手写时容易出偏差。在把这些规则用于自动化之前务必先用内置命令实测。文档给出的用法是interpreter execpolicy check command例如interpreter execpolicy check pnpm test --run unit interpreter execpolicy check rm -rf /结合仓库实现可以进一步理解这条命令的机制。对应的子命令参数定义在 codex-rs/execpolicy/src/execpolicycheck.rs它支持一个或多个--rules PATH策略文件、--pretty美化 JSON 输出以及--resolve-host-executables解析宿主可执行文件的绝对路径命令本身以trailing_var_arg方式接收完整命令行 token。从 CLI 运行同样效果的检查codex execpolicy check --rules path/to/policy.rules git status传入多个--rules时多个策略文件会按传入顺序合并评估加上--pretty可以获得格式化 JSONcodex execpolicy check \ --rules path/to/policy.rules \ --pretty \ git push --force origin main检查结果以 JSON 形式输出包含命中的规则与最终决策{ matchedRules: [ { prefixRuleMatch: { matchedPrefix: [git, push, --force], decision: prompt, justification: force push rewrites remote history } } ], decision: prompt }关键字段的含义与策略文件评估一一对应matchedRules列出所有前缀命中了该命令的规则一条命令可能命中多条规则最终决策取最严格者matchedPrefix实际命中的命令前缀 tokenresolvedProgram仅当通过 basename 回退命中绝对可执行路径时才出现decision整体有效决策allow/prompt/forbidden。当没有任何规则命中时matchedRules为空数组decision字段被省略。开发期间也可以直接用独立 dev 二进制运行cargo run -p codex-execpolicy -- check --rules path/to/policy.rules git status源码透视新一代 execpolicy 引擎与规则格式仓库中的codex-rs/execpolicy是这个执行策略能力的新一代 Rust 实现其使用说明见 codex-rs/execpolicy/README.md旧式规则匹配器则位于codex-execpolicy-legacy。新一代引擎以prefix_rule前缀规则 host_executable宿主可执行文件元数据为最小抽象prefix_rule( pattern [cmd, [alt1, alt2]], # 按序匹配的 token列表表示可选项 decision allow, # allow | prompt | forbidden默认 allow justification explain why this rule exists, match [[cmd, alt1], cmd alt2], # 必须能命中的示例加载期校验 not_match [[cmd, oops], cmd alt3], # 必须不命中的示例加载期校验 )两个值得注意的工程细节match/not_match是规则的单元测试。在策略文件加载时这些示例调用就会被校验字符串会被shlex分词成 token 数组确保模式表达与预期一致。仓库中的完整示例见 codex-rs/execpolicy/examples/example.codexpolicy其中ls、cat这类无显式decision的规则默认即allow而git reset --hard被声明为forbidden并附有justificationdestructive operationcp则被标为prompt。绝对路径与 basename 的匹配策略。引擎总是优先尝试精确的首 token匹配在未开启宿主可执行文件解析时/usr/bin/git status只会命中首 token 为/usr/bin/git的规则开启后则可能回退到针对git的 basename 规则。若存在host_executable(name git, paths [...])声明则 basename 回退只允许命中列表中列出的绝对路径若某 basename 没有任何host_executable()条目则 basename 回退不受限制。这种设计把机器上到底哪个git被调用也纳入了策略考量适合共享/多用户环境。另外引擎还内置了针对approval_policynever等运行模式的行为prompt在该模式下直接被拒绝这也解释了为什么unsafe/prompt在永不批准场景下等效于被拦截而forbid/forbidden在任何场景下都无法绕开。随附的默认策略长什么样前面提到Open Interpreter 随附一个合理的默认策略仓库中旧式引擎的默认策略文件 codex-rs/execpolicy-legacy/src/default.policy 展示了这套默认策略的典型形态它针对ls、cat、cp、head、printenv、pwd、rg、sed、which等高频命令分别用define_program(...)描述其合法 flag、参数类型与可接受的调用形态should_match/should_not_match例如ls只放行-1/-a/-l与文件或当前目录类参数cat允许读取文件、-n/-b等常规 flag但不放行无参数读 stdin的形态sed由于 GNU 实现存在s/.../.../e会执行 shell 命令的潜在风险仅支持被白名单化的已知安全命令子集如-n、-u刻意不支持-i与-f。从这套策略可以看出默认策略的取向让读操作类命令尽量静默放行让可能改变状态或产生副作用的用法退回到人工审批从根上排除高危形态。理解这一点有助于你在自定义规则时把握safe/unsafe/forbid的分寸。编写策略时的注意事项顺序即优先级规则从上到下评估、第一条命中生效。书写时把最具体、最想特判的规则尤其forbid放在最前面防止被前置的宽泛safe规则吞掉。为forbid提供替代建议仓库的新格式规范建议当decision forbidden时在justification中附上推荐的替代命令例如Use jj instead of git.。这让代理在被拒绝时知道下一步该怎么走而不是僵在原地。用自动化测试心态写模式把规则的match/not_match示例当成测试用例维护——每次改动策略后都用execpolicy check验证目标命令的判定结果再投入到自动化流程。共享系统上宁严勿松默认策略适用于单人开发机在共享系统上建议收紧规则面并对所有可能改写状态的命令显式声明unsafe或forbid。预览期注意事项新一代execpolicy命令目前仍处于 preview 阶段见 codex-rs/execpolicy/README.md 的说明其 API 在未来可能发生破坏性变更将策略文件纳入版本管理、并在升级后回归测试是一个稳妥的做法。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Open Interpreter 执行策略（execpolicy）实战：基于规则把命令分类为安全、风险与阻止
Open Interpreter 执行策略execpolicy实战基于规则把命令分类为安全、风险与阻止【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本篇技术指南围绕 Open Interpreter 的 Execution policy执行策略展开它是叠加在沙箱之下的规则层会在每一条命令真正执行前完成一次体检并把命令标记为safe/unsafe/forbid。读完本文你将掌握如何在config.toml中编写规则、理解它与审批approval流程的衔接方式并能借助仓库自带的引擎与execpolicy check命令验证每一条规则是否真正按预期工作。执行策略沙箱之下的第一道规则层Execution policy 位于沙箱sandbox之下是代理执行命令前的第一道过滤。它不像沙箱那样从操作系统层面约束进程能力而是直接看这条命令本身在命令运行之前检查其内容并打上标签。打标结果决定这条命令后续走哪条路径——直接放行、交由审批还是一律拒绝。Open Interpreter 为每条命令分配三类标签标签含义safe常规、低风险。无需提示直接通过。unsafe可能改变系统状态。需要审批。forbid始终阻止。Open Interpreter 随附一套合理的默认策略大多数用户从不编辑它。只有当你想获得更严格的控制或运行在共享系统shared system上时才需要阅读本文并自定义规则。策略存放位置config.toml 与规则评估顺序策略从config.toml加载。每一条规则由两部分构成一个匹配命令的模式pattern以及一个动作action。规则以 TOML 数组的形式写在[[execpolicy.rules]]小节下[[execpolicy.rules]] match ls action safe [[execpolicy.rules]] match rm * action unsafe [[execpolicy.rules]] match rm -rf / action forbid评估时有一个极其关键、也是最容易踩坑的语义规则从上到下逐条评估第一条命中的规则生效The first match wins。这意味着把match rm -rf /写在其父模式rm *之后是安全的——因为rm -rf /本身就是rm *的子集匹配从上到下先命中通用规则则后面的forbid永不生效想让特例覆盖通例必须把更具体的规则放在更靠前的位置模式使用类 shell 的通配符shell-style globs例如rm *中的*、pnpm test*中的*都属于这类通配符匹配。三档标签与审批模式的交互方式执行策略是代理的第一道过滤。策略对命令打标之后forbid直接阻止命令完全不进入后续环节safe在不提示without prompting的情况下直接运行unsafe交由你的审批模式approval mode处理参见沙箱与审批。由此可以推出两条非常实用的性质一条safe规则可以显著减少你一天中弹出的审批次数——你信任的命令例如测试、lint不再打扰你一条forbid规则则提供兜底保证即使你在审批提示中意外按下y该命令也永远不会执行。forbid的拦截发生在审批之前审批根本不会有机会放行它。从仓库中新一代执行策略引擎的源码可以印证这套语义核心决策类型Decision定义在 codex-rs/execpolicy/src/decision.rs包含三档Allow无需进一步审批即可运行Prompt请求用户明确批准当以approval_policy never永不批准模式运行时会被直接拒绝Forbidden不做任何考虑直接阻止。可以推断本文面向的config.toml三档标签safe/unsafe/forbid与上述三档决策在语义上一一对应safe≈allow免审批放行、unsafe≈prompt交由审批、forbid≈forbidden无条件拦截。此外当一条命令同时命中多条规则时引擎会取最严格的严重级别作为最终决策forbiddenpromptallow也就是说只要有任何一条规则把它判为forbidden命令就不会执行。常见模式直接可复用的规则片段让你信任的 lint 与 test 命令完全不触发提示把代理会反复执行、且你完全信任的命令标记为safe可以让日常工作流中的干扰降到最低[[execpolicy.rules]] match pnpm test* action safe [[execpolicy.rules]] match pnpm lint* action safepnpm test*这类前缀模式能同时覆盖pnpm test、pnpm test --run、pnpm test:watch等各种变体。对所有破坏性操作强制确认对可能改变远端状态或造成不可逆后果的命令用unsafe强制人工确认用forbid直接封死[[execpolicy.rules]] match git push --force* action unsafe [[execpolicy.rules]] match drop database* action forbiddrop database这类操作即便是开发库也几乎不该由代理自动执行因此用forbid而不是unsafe是更稳妥的默认选择——毕竟unsafe只代表需要审批而审批仍可能被人为放行。验证规则execpolicy check 命令模式采用类 shell 通配符手写时容易出偏差。在把这些规则用于自动化之前务必先用内置命令实测。文档给出的用法是interpreter execpolicy check command例如interpreter execpolicy check pnpm test --run unit interpreter execpolicy check rm -rf /结合仓库实现可以进一步理解这条命令的机制。对应的子命令参数定义在 codex-rs/execpolicy/src/execpolicycheck.rs它支持一个或多个--rules PATH策略文件、--pretty美化 JSON 输出以及--resolve-host-executables解析宿主可执行文件的绝对路径命令本身以trailing_var_arg方式接收完整命令行 token。从 CLI 运行同样效果的检查codex execpolicy check --rules path/to/policy.rules git status传入多个--rules时多个策略文件会按传入顺序合并评估加上--pretty可以获得格式化 JSONcodex execpolicy check \ --rules path/to/policy.rules \ --pretty \ git push --force origin main检查结果以 JSON 形式输出包含命中的规则与最终决策{ matchedRules: [ { prefixRuleMatch: { matchedPrefix: [git, push, --force], decision: prompt, justification: force push rewrites remote history } } ], decision: prompt }关键字段的含义与策略文件评估一一对应matchedRules列出所有前缀命中了该命令的规则一条命令可能命中多条规则最终决策取最严格者matchedPrefix实际命中的命令前缀 tokenresolvedProgram仅当通过 basename 回退命中绝对可执行路径时才出现decision整体有效决策allow/prompt/forbidden。当没有任何规则命中时matchedRules为空数组decision字段被省略。开发期间也可以直接用独立 dev 二进制运行cargo run -p codex-execpolicy -- check --rules path/to/policy.rules git status源码透视新一代 execpolicy 引擎与规则格式仓库中的codex-rs/execpolicy是这个执行策略能力的新一代 Rust 实现其使用说明见 codex-rs/execpolicy/README.md旧式规则匹配器则位于codex-execpolicy-legacy。新一代引擎以prefix_rule前缀规则 host_executable宿主可执行文件元数据为最小抽象prefix_rule( pattern [cmd, [alt1, alt2]], # 按序匹配的 token列表表示可选项 decision allow, # allow | prompt | forbidden默认 allow justification explain why this rule exists, match [[cmd, alt1], cmd alt2], # 必须能命中的示例加载期校验 not_match [[cmd, oops], cmd alt3], # 必须不命中的示例加载期校验 )两个值得注意的工程细节match/not_match是规则的单元测试。在策略文件加载时这些示例调用就会被校验字符串会被shlex分词成 token 数组确保模式表达与预期一致。仓库中的完整示例见 codex-rs/execpolicy/examples/example.codexpolicy其中ls、cat这类无显式decision的规则默认即allow而git reset --hard被声明为forbidden并附有justificationdestructive operationcp则被标为prompt。绝对路径与 basename 的匹配策略。引擎总是优先尝试精确的首 token匹配在未开启宿主可执行文件解析时/usr/bin/git status只会命中首 token 为/usr/bin/git的规则开启后则可能回退到针对git的 basename 规则。若存在host_executable(name git, paths [...])声明则 basename 回退只允许命中列表中列出的绝对路径若某 basename 没有任何host_executable()条目则 basename 回退不受限制。这种设计把机器上到底哪个git被调用也纳入了策略考量适合共享/多用户环境。另外引擎还内置了针对approval_policynever等运行模式的行为prompt在该模式下直接被拒绝这也解释了为什么unsafe/prompt在永不批准场景下等效于被拦截而forbid/forbidden在任何场景下都无法绕开。随附的默认策略长什么样前面提到Open Interpreter 随附一个合理的默认策略仓库中旧式引擎的默认策略文件 codex-rs/execpolicy-legacy/src/default.policy 展示了这套默认策略的典型形态它针对ls、cat、cp、head、printenv、pwd、rg、sed、which等高频命令分别用define_program(...)描述其合法 flag、参数类型与可接受的调用形态should_match/should_not_match例如ls只放行-1/-a/-l与文件或当前目录类参数cat允许读取文件、-n/-b等常规 flag但不放行无参数读 stdin的形态sed由于 GNU 实现存在s/.../.../e会执行 shell 命令的潜在风险仅支持被白名单化的已知安全命令子集如-n、-u刻意不支持-i与-f。从这套策略可以看出默认策略的取向让读操作类命令尽量静默放行让可能改变状态或产生副作用的用法退回到人工审批从根上排除高危形态。理解这一点有助于你在自定义规则时把握safe/unsafe/forbid的分寸。编写策略时的注意事项顺序即优先级规则从上到下评估、第一条命中生效。书写时把最具体、最想特判的规则尤其forbid放在最前面防止被前置的宽泛safe规则吞掉。为forbid提供替代建议仓库的新格式规范建议当decision forbidden时在justification中附上推荐的替代命令例如Use jj instead of git.。这让代理在被拒绝时知道下一步该怎么走而不是僵在原地。用自动化测试心态写模式把规则的match/not_match示例当成测试用例维护——每次改动策略后都用execpolicy check验证目标命令的判定结果再投入到自动化流程。共享系统上宁严勿松默认策略适用于单人开发机在共享系统上建议收紧规则面并对所有可能改写状态的命令显式声明unsafe或forbid。预览期注意事项新一代execpolicy命令目前仍处于 preview 阶段见 codex-rs/execpolicy/README.md 的说明其 API 在未来可能发生破坏性变更将策略文件纳入版本管理、并在升级后回归测试是一个稳妥的做法。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考