実行モード

実行モードでは、Cherri Code エージェントによるツール呼び出しの実行方法と、Cherri Code が承認を求めて中断するタイミングを制御します。

シェルコマンド、MCP ツール、Fetch 呼び出しについて、エージェントにどの程度の自律性を与えるかを決めます。ほとんどのユーザーには、安全性と利便性のバランスに優れた Auto-review がおすすめです。既知の安全な呼び出しは実行し、可能な場合はシェルコマンドをサンドボックス内で実行し、それ以外は分類器に確認させます。

モードを選択する

デスクトップアプリで、Settings > Agents > Approvals & Execution に移動します。

Auto-review の仕組み

Auto-review は、シェル、MCP、Fetch のツール呼び出しに適用されます。Cherri Code は各呼び出しを次の順序で確認します。

シェル コマンドは、サンドボックスのファイルおよびネットワークの制限内で動作する場合、「サンドボックス内で実行可能」です。ワークスペース外への書き込みや特権操作など、システム全体へのアクセスを必要とするコマンドはサンドボックス化できないため、代わりに 分類器 に送られます。

サンドボックス化は、シェル コマンドにおける実行モードの追加レイヤーです。対応する ターミナルコマンド をどこで実行するかを制御するものであり、そのモードで Auto-review 分類器 を使用するかどうかを制御するものではありません。

分類器 が呼び出しをブロックすると、Cherri Code は別の方法を試すことができます。分類器 の判断に反してもそのアクションが妥当だとエージェントが判断した場合、Cherri Code は承認プロンプトを表示します。

Auto-review 分類器の要件

Auto-review の分類器は、Cherri Code 管理の小規模モデルで実行されます。現在は Claude 4.5 Haiku または GPT-5.4 Mini です。

エンタープライズのモデルアクセス制御が適用されます。これらのモデルのいずれか 1 つがチームで許可されていれば、Auto-review を利用できます。すべてをブロックすると、チームの実行モードに Auto-review が含まれていても、Settings > Agents > Approvals & Execution で Auto-review は無効になります。その場合、メンバーは代わりに許可リストを使用します。

Auto-review がグレーアウトされている場合は、Team Settings → Models でこれらのモデルを有効にし、Cherri Code を完全に終了してから再起動し、Approvals & Execution をもう一度確認してください。

Auto-review の設定

Auto-review を適切に機能させるために設定は必要ありません。常に手動で確認したい特定のアクションがある場合は、平易な英語で記述してください。

最も簡単な設定方法は、Cherri Code エージェントに依頼することです。たとえば「すべての AWS CLI コマンドはまず承認を必要にしてほしい」と伝えると、permissions.json を編集してくれます。

ファイルを自分で編集することもできます。Auto-review は次の 2 か所にある permissions.json を読み取ります。

両方のファイルが存在する場合、Cherri Code はそれらをマージします。個人用の指示とプロジェクトの指示の両方が適用されます。

チームは、ダッシュボードでグローバルな Auto-review 設定を定義することもできます。チーム設定が定義されている場合はそれが優先され、Cherri Code はユーザーレベルおよびプロジェクトレベルのファイルを無視します。

どちらのローカルファイルも同じスキーマを使用します。各指示は平易な英語の文であるため、「すべての 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 はマシン全体へのアクセスを許可せずにターミナルコマンドを実行できます。サンドボックス化されたコマンドはプロジェクト内で動作できますが、保護されたファイルを自由に読み取ったり、承認されたパスの外に書き込んだり、任意のネットワーク宛先に接続したりすることはできません。

技術的な詳細については、Implementing a secure sandbox for local agents をご覧ください。

一部のコマンドにはシステム全体へのアクセスが必要で、サンドボックスをバイパスします。コマンドがサンドボックスの外で実行される場合、Cherri Code はその旨を示し、承認を求めます。

サンドボックスの設定

sandbox.json ファイルでサンドボックスの挙動をカスタマイズできます。

両方のファイルが存在する場合、Cherri Code はそれらをマージし、プロジェクトレベルのファイルを優先します。チーム管理者ポリシーと Cherri Code にハードコードされたセキュリティルールがさらに適用されるため、ローカルファイルでこれらの保護を弱めることはできません。

sandbox.json を使用して、ネットワークポリシー、追加の読み取り・書き込み可能なパス、一時ディレクトリへの書き込み、共有ビルドキャッシュを制御します。完全なスキーマについては、sandbox.json リファレンスを参照してください。

プラットフォーム別のサンドボックス化の仕組み

環境変数

Cherri Code は、サンドボックス化されたすべての子プロセスに環境変数を設定します。これらの環境変数は、サンドボックス内で実行されるスクリプト、ビルドツール、自動化で使用できます。

Docker とコンテナの自動化

自動化ルールやスクリプトでは、ホストユーザーの ID に合わせる必要がある 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

その他の保護機能

実行モードとサンドボックス化だけがセーフティ制御ではありません。以下の保護機能では、モードが自動実行に設定されている場合でも承認が必要になることがあります。

チームの管理

管理者は、ユーザーが利用できるモードを変更したり、ターミナルコマンド用サンドボックスのネットワークルールを設定したりできます。これらすべての設定はWebダッシュボードで利用できます。

チーム設定は、個人およびプロジェクトの設定よりも優先されます。全員に共通の基準を適用したい場合に使用してください。チームでAuto-reviewを有効にする場合は、モデルアクセス制御で分類器が必要とするモデルのいずれかを許可してください。

変更履歴