> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Devin CLI の権限

> Devin CLI の権限ルールを設定し、コマンド、ファイルアクセス、MCP ツールに対して、予測可能な優先順位で許可・拒否・確認を制御します。

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

***

<div id="default-permission-behavior">
  ## デフォルトの権限の動作
</div>

Devin CLI は、機能性と安全性のバランスを取るために、ティア制の権限システムを利用します。デフォルトの動作は、現在の[モード](/ja/cli/essential-commands#modes)によって異なります。

各セルには、そのモードでそのツールが自動的に実行されるか (**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 モード](#smart-mode) を参照してください。

**Bypass モード**では、すべてのツール呼び出しが確認なしで自動承認されます。

**Autonomous モード**では、OS レベルのサンドボックスによってアクセス可能な範囲が制限されるため、シェルコマンドとネットワークFetchは自動承認されます。一方、`edit`/`write` ツールによる直接のファイル編集は、それらのツールがサンドボックスの外で動作するため、引き続き確認が表示されます。Autonomous は、[OS レベルのサンドボックス](#autonomous-mode)がアクティブな場合にのみ利用できます。

<Warning>
  Smart、Bypass モード、Autonomous モードは、組織レベルの権限を**上書きしません**。[チーム設定](/ja/cli/enterprise/team-settings) で構成された管理者適用の拒否ルールおよび ask ルールは、ユーザーの権限モードに関係なく有効なままです。詳しくは [Precedence](#precedence) を参照してください。
</Warning>

<div id="smart-mode">
  ### Smart モード
</div>

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

```bash theme={null}
/smart
# または
/mode smart
```

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

```bash theme={null}
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`) | 常に確認  | 常に確認              | 常に自動   |

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

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

<div id="autonomous-mode">
  ### Autonomous モード
</div>

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

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

```bash theme={null}
devin --sandbox --permission-mode autonomous
```

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

***

<div id="how-permissions-work">
  ## 権限 の仕組み
</div>

エージェントがツールを呼び出すと、同じ設定レベルで一致するルールは次のように解決されます。

1. **拒否ルール** — 一致した場合、その操作はただちにブロックされます。
2. **Ask rules** — 一致した場合、同等以上に具体的なコマンドまたは MCP の allow ルールも一致していない限り、確認を求められます。
3. **Allow rules** — 一致した場合、その操作は確認なしで実行されます。
4. **Default** — 一致するルールがない場合は、承認を求められます。

<Note>
  拒否ルールが常に優先されます。allow ルールがどれほど具体的であっても、一致する拒否ルールを上書きすることはありません。
</Note>

<div id="specific-allow-rules">
  ### 特定の許可ルール
</div>

同じ設定レベルでは、特定のコマンドに対する allow が、より広範な ask に対する例外として機能します。例:

```json theme={null}
{
  "permissions": {
    "ask": ["exec"],
    "allow": ["Exec(git status)"]
  }
}
```

この設定では、`git status` は確認なしで実行され、その他のコマンドでは引き続き確認が求められます。両方のルールがコマンドスコープを使用する場合も同様で、完全一致のコマンドはプレフィックスよりも具体的であり、長いプレフィックスは短いプレフィックスよりも具体的とみなされます。

MCP ルールも同じ原則に従います。特定のツールはサーバー全体のルールよりも具体的であり、サーバー全体のルールはすべての MCP ツールを対象とするルールよりも具体的です。

この例外が適用されるのは、同一の設定レベル内に限られます。下位レベルの allow で、組織設定などより優先度の高いレベルの ask を上書きすることはできません。また、`Read()` や `Write()` のパス glob には適用されません。パスが ask ルールに一致した場合、より狭い範囲のパスの allow にも一致していれば、Devin は確認を求めます。

***

<div id="configuration">
  ## 設定
</div>

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

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

<Tabs>
  <Tab title="プロジェクト設定">
    ```json theme={null}
    // .devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(src/**)",
          "Exec(npm run)"
        ],
        "deny": [
          "Exec(rm)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="ユーザー設定">
    ```json theme={null}
    // ~/.config/devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(**)",
          "Exec(git)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="ローカルオーバーライド">
    ```json theme={null}
    // .devin/config.local.json
    {
      "permissions": {
        "allow": [
          "Exec(docker compose)"
        ]
      }
    }
    ```
  </Tab>
</Tabs>

***

<div id="permission-syntax">
  ## 権限の構文
</div>

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

<div id="scope-based-permissions">
  ### スコープベースの権限
</div>

<AccordionGroup>
  <Accordion title="Read(glob)" icon="eye" defaultOpen>
    ファイルの読み取り権限を制御します。glob パターンはファイルパスにマッチします。

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

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

  <Accordion title="Write(glob)" icon="pen">
    ファイルの書き込み/編集権限を制御します。

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

  <Accordion title="Exec(prefix)" icon="terminal">
    シェルコマンドの実行権限を制御します。指定したプレフィックスで始まるコマンドにマッチします。

    ```json theme={null}
    "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 コマンドをブロック
    ]
    ```

    <Note>
      `Exec(git)` は "git"、"git status"、"git commit -m 'msg'" にはマッチしますが、"gitk" や "github-cli" にはマッチしません。プレフィックスは完全な単語として一致する必要があります。
    </Note>
  </Accordion>

  <Accordion title="Fetch(pattern)" icon="globe">
    URL パターンを使って HTTP fetch 権限を制御します。

    ```json theme={null}
    "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](https://urlpattern.spec.whatwg.org/) 標準に従います。`domain:` の省略記法は、完全一致するドメイン上の任意のパスにマッチします。
  </Accordion>
</AccordionGroup>

<div id="tool-based-permissions">
  ### ツールベースの権限
</div>

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

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

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

<div id="mcp-tool-permissions">
  ### MCP ツールの権限
</div>

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

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

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

***

<div id="path-patterns">
  ## パスパターン
</div>

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

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

**使用例:**

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

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

***

<div id="persistence-options">
  ## 永続化オプション
</div>

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

| オプション              | 保存場所                                                                     | チームで共有されるか |
| ------------------ | ------------------------------------------------------------------------ | ---------- |
| 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 を常に許可する」オプションが追加されます。

<div id="editing-a-command-before-approving">
  ### 承認前に Command を編集する
</div>

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

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

<div id="mcp-server-level-grants">
  ### MCPサーバーレベルの権限付与
</div>

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

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

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

***

<div id="precedence">
  ## 優先順位
</div>

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

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

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

***

<div id="examples">
  ## 使用例
</div>

<div id="minimal-development-setup">
  ### 最小限の開発構成
</div>

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

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}
```

<div id="full-trust-for-a-project">
  ### プロジェクトを全面的に信頼する
</div>

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

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

<div id="locked-down-enterprise">
  ### 厳格に制限された Enterprise
</div>

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

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

<Tip>
  この例では、`.env*` への書き込みは無条件で拒否され、それ以外の書き込みはすべて常にユーザーに確認を求めます。また、特定のコマンドに対する allow は、同じ設定レベルにあるより広範な `exec` の ask を上書きできます。`.env*` の拒否は引き続き `Write(**)` の ask ルールよりも優先されます。
</Tip>