権限 - Devin Docs

権限システムでは、エージェントがあなたの承認なしに実行できる操作を制御します。安全な操作は事前に承認し、危険なものはブロックし、機密性の高い操作では常に確認を求めるようにできます。

デフォルトの権限の動作

Devin CLI は、機能性と安全性のバランスを取るために、ティア制の権限システムを利用します。デフォルトの動作は、現在のモードによって異なります。各セルには、そのモードでそのツールが自動的に実行されるか (Auto、確認なし) 、承認を待つか (Prompt) が示されています:

Tool type	Example	Normal	Accept Edits	Smart	Bypass	Autonomous (sandbox)
読み取り専用	ファイルの読み取り、grep、glob	Auto	Auto	Auto	Auto	Auto
Fetch	HTTP リクエスト	Prompt	Prompt	安全と判断された場合は Auto	Auto	Auto
Bash コマンド	シェルの実行	Prompt	Prompt	安全と判断された場合は Auto	Auto	Auto
`edit`/`write` によるファイル編集	ファイルの編集/書き込み	Prompt	Auto (ワークスペース内)	Auto (ワークスペース内)	Auto	Prompt

Normal モード (デフォルト) では、読み取り専用の操作は自動承認されますが、書き込み操作とシェルコマンドの実行には明示的な承認が必要です。アクションを承認するたびに、1 回だけ許可するか、セッション中は許可するか、またはプロジェクトに対して永続的に許可するかを選択できます。 Accept Edits モードでは、ワークスペース内のファイル編集は自動承認されますが、シェルコマンドとワークスペース外への書き込みでは引き続き確認が表示されます。 Smart モードでは、Accept Edits と同様にワークスペース内の編集が自動承認され、その他のすべてのアクションは高速モデルによって判定され、明らかに安全な場合にのみ自動実行されます。それ以外の場合は通常どおり確認が表示されます。以下の Smart モードを参照してください。 Bypass モードでは、すべてのツール呼び出しが確認なしで自動承認されます。 Autonomous モードでは、OS レベルのサンドボックスによってアクセス可能な範囲が制限されるため、シェルコマンドとネットワークFetchは自動承認されます。一方、edit/write ツールによる直接のファイル編集は、それらのツールがサンドボックスの外で動作するため、引き続き確認が表示されます。Autonomous は、OS レベルのサンドボックスがアクティブな場合にのみ利用できます。

Smart、Bypass モード、Autonomous モードは、組織レベルの権限を上書きしません。チーム設定で構成された管理者適用の拒否ルールおよび ask ルールは、ユーザーの権限モードに関係なく有効なままです。詳しくは Precedence を参照してください。

Smart モード

Smart は、Accept Edits と Bypass の中間に位置するモードです。ワークスペース内のファイル編集は、Accept Edits と同様に自動承認されます。それ以外のすべてのアクション (シェルコマンド、Web Fetch、MCP ツール、ワークスペース外への書き込み) については、高速モデルが無人で実行しても安全かどうかを判断します。明らかに安全な場合はプロンプトなしで実行されます。安全でない場合や、モデルが判断できない、または利用できない場合は、通常の承認プロンプトが表示されます。

/smart
# または
/mode smart

Shift+Tab でSmartに切り替えるか、モードセレクターで選択するか、Smartモードで開始できます：

devin --permission-mode smart
# または
DEVIN_PERMISSION_MODE=smart devin

モデルによる判断の対象は、ビルド、テスト、lint、フォーマット、プロジェクトの調査といった通常の開発作業に限られます。モデルがどう判断しても、Smart モードでは一部のカテゴリが決して自動承認されません。

パッケージのインストール (npm install、pip install、cargo install、brew install、…)
変更を伴う git 操作 (git status などの読み取り専用サブコマンドは引き続き対象です)
rm、sudo、その他の破壊的なコマンドや権限昇格コマンド
kubectl delete および破壊的なクラウド CLI 操作 (aws、gcloud、az、terraform、…)
dotenv ファイル、鍵マテリアル、Git 設定、エージェント自身の設定を読み書きするすべての操作

Smart は、委任する対象がほかのモードとは異なります。

	編集を承認	Smart	Bypass
ワークスペースのファイル編集	自動	自動	自動
シェルコマンドとFetch	常に確認	モデルが安全と判断した場合のみ自動	常に自動
高リスクコマンド (インストール、`rm`、`sudo`、変更を伴う `git`)	常に確認	常に確認	常に自動

独自のルールが引き続き最優先されます。Smart の判断は、既存のルールで判断されていない場合にのみ適用されます。そのため、Permissions の仕組みで説明しているとおり、deny ルールは操作をブロックし、ask ルールは常に確認を求めます。組織レベルの拒否ルールと ask ルールも同様に影響を受けません。

Smart モードは段階的に展開されているため、まだモードセレクターや Shift+Tab による切り替えに表示されない場合があります。

Autonomous モード

Autonomous は、--sandbox フラグと組み合わせて使う権限モードです。概念的には、これはおおむね「現在のワークスペースで編集を受け入れる」に、任意のシェルコマンドを実行する機能を加えたもので、どちらの動作も OS レベルのサンドボックス内に制限されます。サンドボックスがアクティブな場合:

利用できる権限モードはこれだけです。 サンドボックスのセッションでは、Normal、Accept Edits、Smart、Bypass は表示されません。Plan モードは引き続き利用できます。
シェルコマンドとFetchは、確認なしで自動承認されます。 サンドボックスによって、それらが読み取り・書き込みできる範囲や、ネットワーク経由で到達できる範囲が制限されるためです。
edit および write ツールによるファイルの直接編集では、引き続き確認が求められます。 これらのツールはサンドボックス内ではなく CLI プロセス内で実行されるため、サンドボックスで制限できません。プロンプトで Write(...) スコープを付与すると、以後のシェルコマンドがその場所に書き込めるよう、サンドボックスが動的に拡張されます。
セッションの途中で付与された Write(...) スコープによって、以後のコマンドに対するサンドボックスの範囲が動的に拡張されます。 セッション途中の Read(...) 承認はエージェント自身のツールにのみ影響します。Read(...) 拒否ルールによって非表示になっているパスは、セッション全体を通して非表示のままです。

devin --sandbox --permission-mode autonomous

OS レベルの分離なしで制限なく実行したい場合は Bypass を利用し、ファイルシステムとネットワークアクセスに OS による制限が適用された無人実行を行いたい場合は --sandbox (Autonomous が選択されます) を利用してください。書き込み可能なルート、拒否ルール、ドメインフィルタリングの詳細についてはサンドボックス設定リファレンスを、Enterprise 向けの制御についてはチーム設定 → サンドボックス強制を参照してください。

権限の仕組み

エージェントがツールを呼び出すと、権限システムは優先順位に従ってルールを確認します。

Deny rules — 最初に確認されます。一致した場合、その操作はただちにブロックされます。
Ask rules — 次に確認されます。一致した場合は、常に確認を求められます (allow ルールより優先されます) 。
Allow rules — 最後に確認されます。一致した場合、その操作は確認なしで実行されます。
Default — 一致するルールがない場合は、承認を求められます。

deny は ask より先に確認され、ask は allow より先に確認されるため、deny ルールが常に優先されます。同じスコープが deny ルールと ask ルールの両方に一致する場合は、deny が適用されます。

設定

設定ファイルの permissions セクションに権限を追加します。

Windows では、ユーザー設定ファイルのパスは ~/.config/devin/config.json ではなく、%APPDATA%\devin\config.json (通常は C:\Users\<you>\AppData\Roaming\devin\config.json) です。詳しくは Configuration File を参照してください。

プロジェクト設定
ユーザー設定
ローカルオーバーライド

// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

// ~/.config/devin/config.json
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git)"
    ]
  }
}

// .devin/config.local.json
{
  "permissions": {
    "allow": [
      "Exec(docker compose)"
    ]
  }
}

権限の構文

権限マッチャーには、スコープベース (アクセス可能なパス、コマンド、URL を制御) と、ツールベース (利用可能なツールを制御) の 2 種類があります。

スコープベースの権限

Read(glob)

ファイルの読み取り権限を制御します。glob パターンはファイルパスにマッチします。

"allow": [
  "Read(src/**)",           // src/ 配下のすべてのファイル
  "Read(~/.config/**)",     // ホームディレクトリの設定ファイル
  "Read(/tmp/**)"           // 一時ディレクトリ
]

ディレクトリパスは、その配下のすべてのファイルに自動的にマッチします。

Write(glob)

ファイルの書き込み/編集権限を制御します。

"allow": [
  "Write(src/**)",          // src/ 配下の任意の場所に書き込み可能
  "Write(tests/**)"         // テストファイルに書き込み可能
],
"deny": [
  "Write(*.lock)",          // lock ファイルは変更不可
  "Write(.env*)"            // env ファイルは変更不可
]

Exec(prefix)

シェルコマンドの実行権限を制御します。指定したプレフィックスで始まるコマンドにマッチします。

"allow": [
  "Exec(git)",              // git、git status、git commit...
  "Exec(npm run)",          // npm run test、npm run build...
  "Exec(python)"            // python、python script.py...
],
"deny": [
  "Exec(rm)",               // rm、rm -rf などをブロック
  "Exec(sudo)"              // sudo コマンドをブロック
]

Exec(git) は “git”、“git status”、“git commit -m ‘msg’” にはマッチしますが、“gitk” や “github-cli” にはマッチしません。プレフィックスは完全な単語として一致する必要があります。

Fetch(pattern)

URL パターンを使って HTTP fetch 権限を制御します。

"allow": [
  "Fetch(https://api.github.com/*)",    // GitHub API
  "Fetch(https://*.example.com/*)",     // example.com のすべてのサブドメイン
  "Fetch(domain:npmjs.org)"             // npmjs.org 上の任意の URL
]

URL パターンは WHATWG URL Pattern 標準に従います。domain: の省略記法は、完全一致するドメイン上の任意のパスにマッチします。

ツールベースの権限

ツール名で一致させることで、ツール全体を制御できます:

{
  "permissions": {
    "deny": [
      "edit",       // すべてのファイル編集をブロック
      "exec"        // すべてのコマンド実行をブロック
    ],
    "allow": [
      "read",       // すべてのファイル読み取りを許可
      "grep",       // すべての検索を許可
      "glob"        // すべてのファイル検索を許可
    ]
  }
}

使用可能なツール名: read, edit, grep, glob, exec

MCP ツールの権限

MCP サーバー上のツールへのアクセスを制御します:

{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // 特定のサーバー上の特定のツール
      "mcp__github__*",               // GitHubサーバー上のすべてのツール
      "mcp__*"                        // すべてのMCPツール
    ],
    "deny": [
      "mcp__github__delete_repo"      // 特定の危険なツールをブロック
    ]
  }
}

パターン	一致対象
`mcp__server__tool`	特定の1つのツール
`mcp__server__*`	サーバー上のすべてのツール
`mcp__*`	あらゆる場所のすべてのMCPツール

パスパターン

Read() と Write() では、以下の glob パターンをサポートしています。

Pattern	Meaning
`*`	1 つのパスセグメント内の任意の文字
`**`	パスセグメントをまたぐ任意の文字 (再帰的)
`~`	ホームディレクトリの展開

使用例:

"allow": [
  "Read(**)",                    // すべての場所のすべてのファイル
  "Read(src/**/*.ts)",           // src/ 内のすべての TypeScript ファイル
  "Write(~/projects/myapp/**)"   // 特定のプロジェクトへの書き込み
]

システム上のすべてのファイルを対象にしたい場合は、絶対パスのプレフィックス (例: Read(/**)) を使用してください。先頭に / のない Read(**) は現在の作業ディレクトリからの相対パスとして解決されるため、そのディレクトリ配下のファイルにしか一致せず、他の場所にある絶対パス経由のファイルには一致しません。

永続化オプション

セッション中にエージェントが許可を求めた場合、その選択をどのように保存するかを選べます。

オプション	保存場所	チームで共有されるか
1回のみ許可	保存されない	いいえ
セッション中のみ許可	メモリ内のみ	いいえ
プロジェクト全体で許可	`.devin/config.json`	はい
プロジェクト全体で許可 (ローカル)	`.devin/config.local.json`	いいえ
グローバルに許可	`~/.config/devin/config.json` (`%APPDATA%\devin\config.json` on Windows)	いいえ

Command のプロンプトでは、両方のスコープが明示的に提示されます。「はい、<project> 内の <cmd> コマンドを常に許可する」を選択すると現在のプロジェクトに対する許可が保存され、「はい、すべてのプロジェクトで <cmd> コマンドを常に許可する」を選択するとユーザー設定に保存され、すべてのプロジェクトに適用されます。特定の URL またはドメインに対する Web Fetch のプロンプトには、フェッチを許可リストに一括追加する、同等の「はい、すべての Web Fetch を常に許可する」オプションが追加されます。

承認前に Command を編集する

Command の承認プロンプトは、単なる「はい」か「いいえ」かの選択ではありません。承認オプションに加えて、コマンドプロンプトでは次の操作を選択できます。

オプション	効果
コマンドを編集	提案されたコマンドをインラインで編集できるように開き、実行前に調整できます
コマンドへの変更を説明	実行したい内容を平易な言葉で説明するとコマンドが書き換えられ、実行前に確認できます

MCPサーバーレベルの権限付与

特定のMCPツール (例: Figmaサーバー上のlist_issues) の許可を求められた場合、権限プロンプトには、より広いサーバーレベルの選択肢も表示されます。

Option	Effect
このツールを許可する (このセッション)	現在のセッション中、その特定のツールへのアクセスを許可します
このツールを常に許可する	その特定のツールへの許可を設定に保存します
このサーバー上のすべてのツールを許可する (このセッション)	このセッション中、そのサーバー上のすべてのツールへのアクセスを許可します
このサーバー上のツールを常に許可する	サーバー全体へのアクセス許可を設定に保存します

これにより、信頼できるMCPサーバーに対して、各ツールを個別に承認しなくても、まとめてすばやくアクセスを許可できます。

優先順位

複数の権限ソースでルールが定義されている場合、以下の優先順位 (高い順) でマージされます。

組織/チームの設定 (Enterprise の場合)
セッションレベルの付与 (対話的な承認)
プロジェクトのローカル設定 (.devin/config.local.json)
プロジェクト設定 (.devin/config.json)
ユーザー設定 (~/.config/devin/config.json、Windows では %APPDATA%\devin\config.json)

組織レベルでの拒否設定は、プロジェクト設定やユーザー設定で上書きできません。これにより、Enterprise のポリシーが確実に適用されます。

使用例

最小限の開発構成

一般的な読み取り専用の操作は許可し、それ以外はすべて確認を求めます：

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}

プロジェクトを全面的に信頼する

プロジェクト内のほとんどの操作を自動承認します：

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}

厳格に制限された Enterprise

安全な特定の操作のみに限定し、書き込み時は常に確認を求める:

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}

この例では、.env* への書き込みは無条件で拒否され、それ以外の書き込みはすべて常にユーザーに確認を求めます。また、自動承認されるのは一部の読み取り専用コマンドのみです。deny は ask より先にチェックされるため、.env* の拒否は Write(**) の ask ルールよりも優先されます。

導入ガイド

Editorとの統合

拡張性

Enterprise

リファレンス

変更ログ

権限

デフォルトの権限の動作

Smart モード

Autonomous モード

権限の仕組み

設定

権限の構文

スコープベースの権限

ツールベースの権限

MCP ツールの権限

パスパターン

永続化オプション

承認前に Command を編集する

MCPサーバーレベルの権限付与

優先順位

使用例

最小限の開発構成

プロジェクトを全面的に信頼する

厳格に制限された Enterprise

​デフォルトの権限の動作

​Smart モード

​Autonomous モード

​権限 の仕組み

​設定

​権限の構文

​スコープベースの権限

​ツールベースの権限

​MCP ツールの権限

​パスパターン

​永続化オプション

​承認前に Command を編集する

​MCPサーバーレベルの権限付与

​優先順位

​使用例

​最小限の開発構成

​プロジェクトを全面的に信頼する

​厳格に制限された Enterprise

デフォルトの権限の動作

Smart モード

Autonomous モード

権限の仕組み

設定

権限の構文

スコープベースの権限

ツールベースの権限

MCP ツールの権限

パスパターン

永続化オプション

承認前に Command を編集する

MCPサーバーレベルの権限付与

優先順位

使用例

最小限の開発構成

プロジェクトを全面的に信頼する

厳格に制限された Enterprise