Muse Codeの権限プロファイルとコマンド承認の設定|Auto-reviewと「Always allow」の使い分け
Muse Codeの権限プロファイルは、セッションを「どこまでAIに任せる状態で始めるか」を決める設定です。Ask me・Auto-review・Read-only・Unrestrictedの4種類があり、初期設定はAuto-review。この記事では、Metaの公式ドキュメントをもとに、4つの違い、承認の画面で選べること、許可ルールの考え方、ガードレールを外すフラグを整理します。
権限プロファイルとは:4種類の違い
公式ドキュメントでは、権限プロファイルを「セッションが始まるときの姿勢」と説明しています。新しいセッションはAuto-reviewで始まり、選んだプロファイルは記憶されて次のセッションにも使われます。
| プロファイル | 動き | 向く場面 |
|---|---|---|
| Ask me | 承認が必要な操作を、すべて自分で判断する | 初めてのリポジトリ、重要なコード |
| Auto-review(初期設定) | アクセス範囲はAsk meと同じ。承認が必要な操作を自動のレビュアー(approval judge)が判断する。使えないときは自分に確認が来る | ふだんの作業 |
| Read-only | ワークスペースは読めるが、ファイルの書き込みや副作用のあるコマンドは実行できない | コードの調査・レビューだけ頼むとき |
| Unrestricted | 承認もサンドボックスもなし。ワークスペースを信頼した状態で動く(--yoloと同じ姿勢) | 使い捨ての隔離環境のみ |
Ask meとAuto-reviewは、どちらも初期設定の承認モード on-request で動きます。違いは「承認の判断を誰がするか」だけです。
設定ファイルで初期プロファイルを決める
設定ファイル ~/.config/muse/settings.json の permissions.default_profile が、初期のプロファイルを決めるキーです。ただし、設定できる値の綴りは公式ドキュメントで確認できませんでした。また、セッション中にプロファイルを切り替えるコマンドやキー操作も、確認できませんでした。実際の切り替え方は、画面の表示や muse --help で確かめてください。
Auto-reviewの仕組み:approval judgeを切る方法
Auto-reviewでは、承認が必要な操作をapproval judgeという自動レビュアーが判断します。判断を自分で行いたいときは、起動時に次のオプションを付けます。
muse --approval-judge off
judgeを切ると、すべてのレビュー判断が自分に回ってきます。既定はオンです。
承認モード(--approval-mode)との関係は次のとおりです。
- on-request(既定):認識できる安全なシェルの処理は確認なしで通る。大量の削除や、補助プロセスを起動しうるripgrepのオプション(
-z、--search-zip、--pre、--hostname-bin)などは確認で止まる - untrusted:一致する許可ルールがないシェルの処理は、すべて確認で止まる
- never:承認では何も止まらず、サンドボックスだけで守る
どのモードでも、ファイルの読み取りと、ワークスペース内での write_file / edit_file による書き込みは、承認なしで行えます。
承認の画面で選べること:Allow onceとAlways allow
Muse Codeは、&& でつないだ複合コマンドを1つずつの段階に分けて評価します。公式の例は次のとおりです。
wc -l report.log && echo cleaning && rm -rf report.log
この場合、止まるのは3段階目の rm -rf report.log だけです。ただし拒否すると、安全な前の2段階も含めて何も実行されません。
確認の画面では、次の3つから選べます。
| 選択肢 | 動き |
|---|---|
| Allow once | 1回だけ実行する。何も保存しない |
| Always allow in this workspace | そのコマンドの先頭部分(prefix)を許可ルールとして、今のワークスペースのルートに紐づけて保存する。ほかのプロジェクトには効かない |
| Reject | コマンド全体を拒否する |
許可ルールの注意点
- denyルール(拒否)は、どれだけ細かい指定のallowルールがあっても、常にallowより優先される
python・bash・nodeのようなインタープリタ(実行環境)のprefixは、広い許可として保存できない- 許可ルールやdenyルールのファイルの書き方(キー名・パターン)は、権限と設定の公式ページでは確認できませんでした
ガードレールを外す3つのフラグの違い
承認とサンドボックスは、別々に外せます。外す範囲が違うので、目的に合うものを選びます。
| フラグ | 外れるもの | 残るもの |
|---|---|---|
--disable-approval | 承認 | サンドボックス |
--disable-sandbox | サンドボックス(ファイル書き込みのワークスペース制限も外れ、ネットワークは制限なしになる) | 承認 |
--yolo | 承認とサンドボックスの両方。ワークスペースも信頼済みになる | なし |
公式ドキュメントは、--yolo を「環境もコードも信頼できる場所、たとえば使い捨てのCIコンテナ」だけで使うよう注意しています。無人で動かしたいだけなら、まず --disable-approval でサンドボックスを残すほうが安全です。
無人実行(muse exec)と、プロファイルが選べないとき
画面なしで動かす muse exec は、承認の質問に答えられません。公式ドキュメントでは、無人で完結する設定を選ぶか、承認待ちのまま残る前提で使うよう案内しています。
また、追加のフォルダやdenyパターンといったファイルシステムのルールを強制できない環境では、そのプロファイルは選択時に理由つきで拒否されます。読み取り専用で動かしたい場合は、環境変数 MUSE_PERMISSION_PROFILE_FAIL_OPEN=1 を設定すると動かせます(起動時に警告が出ます)。
初めて開くフォルダでは、ワークスペースを信頼するか聞かれます。信頼すると、そのフォルダのskills・rules・hooksが読み込まれます。信頼はワークスペースごとに記憶されます。
よくある質問(FAQ)
Q. 初期設定のままで安全ですか?
初期設定のAuto-reviewは、サンドボックスと承認が有効な状態で始まります。ただし公式の説明では、サンドボックスの外で動くMCPやhooksもあるため、つなぐものは中身を確認してから使ってください。
Q. 調査だけ頼みたいときは?
Read-onlyなら書き込みや副作用のあるコマンドは実行されません。
Q. 承認の質問が多くて面倒です。
よく使う安全なコマンドは、承認の画面で「Always allow in this workspace」を選べば、そのワークスペースでは聞かれなくなります。別のプロジェクトには広がりません。
Q. 権限の設定をまとめて管理者が決められますか?
設定ファイルの検証コマンド(muse config validate、muse config status)はありますが、組織向けの権限ポリシーの詳しい書き方は確認できませんでした。
まとめ
- 権限プロファイルは4種類。初期設定のAuto-reviewは、承認の判断を自動レビュアーに任せる
- 承認の画面では、Allow once・Always allow in this workspace・Rejectを選べる。denyはallowより優先
- ガードレールは
--disable-approval・--disable-sandbox・--yoloで外す範囲が違う - プロファイルの切り替え操作と、許可ルールの書式は、公式ページで確認できなかった
承認モードやサンドボックスの基本はMuse Codeの使い方で説明しています。
出典:Meta Muse Code Permissions、Configuration(いずれも dev.meta.ai/docs)。内容は記事作成時点のものです。

