运行模式

运行模式决定 Cherri Code 智能体如何执行工具调用，以及 Cherri Code 会在何时中断并请求您批准。

您可以通过它们决定智能体在执行 shell 命令、MCP 工具和 Fetch 调用时拥有多大的自主权。对大多数人来说，最安全且实用的设置是 Auto-review 模式。它会执行已知安全的调用，在可能的情况下将 shell 命令置于沙盒中运行，并让分类器评审其他操作。

选择模式

在桌面端应用中，前往 设置 > 代理 > 批准与执行。

Auto-review 模式的工作原理

Auto-review 模式适用于 shell、MCP 和 Fetch 工具调用。Cherri Code 会按以下顺序检查每个调用：

如果 shell 命令在沙盒的文件和网络限制下能够正常运行，就表示它“可以在沙盒中运行”。需要完整系统访问权限的命令，例如在工作区外写入或执行特权操作，无法在沙盒中运行，因此会交由分类器处理。

对于 shell 命令，沙盒机制是运行模式之上的一层机制。它控制受支持的终端命令在哪里运行，而不决定该模式是否使用 Auto-review 模式分类器。

当分类器阻止某个调用时，Cherri Code 可以尝试其他方法。如果智能体认为尽管分类器作出了这一判断，该操作仍然合理，Cherri Code 会向你显示批准提示。

Auto-review 分类器要求

Auto-review 模式的分类器使用小型 Cherri Code 托管模型运行。目前为 Claude 4.5 Haiku 或 GPT-5.4 Mini。

企业版模型访问控制适用。团队获准使用上述任一模型时，即可使用 Auto-review 模式。即使团队的运行模式中包含 Auto-review 模式，若所有这些模型均被阻止，设置 > agents > 批准与执行中的 Auto-review 模式也会被禁用。成员将改用允许列表。

如果 Auto-review 模式显示为灰色，请在团队设置 → 模型中启用这些模型，完全退出并重新打开 Cherri Code，然后再次检查“批准与执行”。

配置 Auto-review 模式

Auto-review 模式无需配置即可正常运行。如果有某些操作您始终希望手动评审，可以用自然语言描述这些操作。

最简单的设置方式是让 Cherri Code 智能体完成。您可以对它说：“我希望每条 AWS CLI 命令都先获得批准”，它会为您编辑 permissions.json。

您也可以自行编辑该文件。Auto-review 模式会从以下两个位置读取 permissions.json：

如果两个文件都存在，Cherri Code 会将其合并。您的个人指令和项目指令都会生效。

团队也可以在仪表盘中定义全局 Auto-review 模式配置。定义团队配置后，其优先级更高，Cherri Code 会忽略用户级和项目级文件。

两个本地文件使用相同的 schema。每条指令都是一句自然语言，因此，“我希望每条 AWS CLI 命令都先获得批准”这样的请求会直接映射到 block_instructions：

{  "autoRun": {    "allow_instructions": [],    "block_instructions": [      "Every AWS CLI command should go through approval first.",      "Every command that modifies Kubernetes resources should go through approval first."    ]  }}

• allow_instructions 用于描述 Auto-review 应优先允许的操作。
• block_instructions 用于描述 Auto-review 应优先阻止的操作，以便智能体选择其他路径或请求你批准。

有关策略设计的更多信息，请参阅使用 Auto-review 管理智能体自主性。

沙盒机制

沙盒机制让 Cherri Code 能够运行终端命令，而无需授予其对机器的完全访问权限。沙盒中的命令可以在项目内运行，但不能随意读取受保护的文件、写入获准路径之外的位置，或连接任意网络目标。

如需深入了解工程实现，请阅读为本地智能体实现安全沙盒。

有些命令需要完全的系统访问权限，因此会绕过沙盒。命令在沙盒外运行时，Cherri Code 会提示你并请求批准。

沙箱配置

通过 sandbox.json 文件自定义沙箱行为：

如果两个文件都存在，Cherri Code 会合并它们，并以项目级文件为准。团队管理员策略和 Cherri Code 内置的硬性安全规则会叠加生效，因此本地文件无法削弱这些保护措施。

使用 sandbox.json 控制网络策略、额外的可读或可写路径、临时目录写入和共享构建缓存。完整 schema 请参阅 sandbox.json 参考。

沙箱如何在您的平台上运行

环境变量

Cherri Code 会向每个沙盒化子进程注入环境变量。沙盒内运行的脚本、构建工具和自动化均可使用这些变量。

Docker 和容器自动化

自动化规则和脚本中常见的一种做法是运行需要与主机用户身份一致的 Docker 容器。由于沙盒会在 Linux 上重新映射 UID，使用 $(id -u) 会得到错误的值。请改用 CURSOR_ORIG_* 变量：

docker run --rm \  --user "${CURSOR_ORIG_UID:-$(id -u)}:${CURSOR_ORIG_GID:-$(id -g)}" \  -v "$PWD:/work" -w /work \  my-image build

${CURSOR_ORIG_UID:-$(id -u)} 这一回退机制可确保该命令在沙箱外也能运行，因为此时变量未设置。

网络访问

选择受沙盒限制的终端命令访问网络的方式：

*.cloudflarestorage.com*.docker.com*.docker.io*.googleapis.com*.githubusercontent.com*.gvt1.com*.public.blob.vercel-storage.com*.yarnpkg.comalpinelinux.organaconda.comapache.orgapt.llvm.orgarchive.ubuntu.comarchlinux.orgawscli.amazonaws.comazure.combinaries.prisma.shbitbucket.orgcentos.orgcloudflarestorage.comcocoapods.orgcodeload.github.comcpan.orgcrates.iodebian.orgdl.google.comdocker.comdocker.iodot.netdotnet.microsoft.comeclipse.orgfedoraproject.orgfiles.pythonhosted.orgfonts.gstatic.comgcr.ioghcr.iogithub.comgitlab.comgolang.orggoogle.comgoproxy.iogradle.orghaskell.orghashicorp.comhex.pmindex.crates.iojava.comjava.netjson-schema.orgjson.schemastore.orgk8s.iolaunchpad.netmaven.orgmcr.microsoft.commetacpan.orgmicrosoft.commise.runnodejs.orgnpm.duckdb.orgnpmjs.comnpmjs.orgnuget.orgoracle.compackagecloud.iopackages.microsoft.compackagist.orgpkg.go.devplaywright.azureedge.netppa.launchpad.netproxy.golang.orgpub.devpublic.blob.vercel-storage.compublic.ecr.awspypa.iopypi.orgpypi.python.orgpythonhosted.orgquay.ioregistry.npmjs.orgregistry.yarnpkg.comrepo.maven.apache.orgruby-lang.orgrubygems.orgrubyonrails.orgrustup.rsrvm.iosecurity.ubuntu.comsh.rustup.rssourceforge.netspring.iostatic.crates.iostatic.rust-lang.orgsum.golang.orgswift.orgubuntu.comvisualstudio.comyarnpkg.comziglang.org

其他保护机制

运行模式和沙盒机制并非仅有的安全控制措施。即使某个模式本应自动运行，以下保护机制仍可能要求批准：

团队控制

管理员可以设置用户可用的模式，还可配置终端命令的沙盒网络规则等。所有这些设置均可在网页端仪表盘中管理。

团队设置优先于个人和项目配置。需要为所有成员设定统一的基准时，请使用这些设置。如果您为团队启用 Auto-review 模式，请确保在模型访问控制中允许分类器所需的模型之一。

更新日志