Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions docs/cli/configuration/settings.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,7 @@ Local overrides merge on top of the corresponding `settings.json` at the same le
| `soundFocusMode` | `always`, `focused`, `unfocused` | `always` | When to play sound notifications. |
| `commandAllowlist` | Array of commands | Safe defaults provided | Commands that run without extra confirmation. |
| `commandDenylist` | Array of commands | Restrictive defaults provided | Commands that always require confirmation. |
| `commandBlocklist` | Array of commands | `[]` (none) | Commands that can never run, even when approvals are skipped. |
| `includeCoAuthoredByDroid` | `true`, `false` | `true` | Automatically append the Droid co-author trailer to commits. |
| `enableDroidShield` | `true`, `false` | `true` | Enable secret scanning and git guardrails. |
| `hooksDisabled` | `true`, `false` | `false` | Globally disable all hooks execution. |
Expand Down Expand Up @@ -135,25 +136,27 @@ The `ideAutoConnect` setting controls whether droid automatically connects to yo
- **`true`** – Auto-connect to IDE from any terminal


## Command allowlist & denylist
## Command allowlist, denylist & blocklist

Use these settings to control which commands droid can execute automatically and which it must never run:

- **`commandAllowlist`** – Commands in this array are treated as safe and run without additional confirmation, regardless of autonomy prompts. Include only low-risk utilities you rely on frequently (for example `ls`, `pwd`, `dir`).
- **`commandDenylist`** – Commands in this array always require confirmation and are typically blocked because they are destructive or unsafe (for example recursive `rm`, `mkfs`, or privileged system operations).
- **`commandDenylist`** – Commands in this array always require confirmation and are typically blocked because they are destructive or unsafe (for example recursive `rm`, `mkfs`, or privileged system operations). A denied command can still be run if you explicitly approve it.
- **`commandBlocklist`** – Commands in this array can **never** run. Unlike the denylist, there is no prompt and no way to approve them: the block applies even under full autonomy, auto-run, or `--skip-permissions-unsafe`. droid also resolves the actual program being invoked, so a blocked command cannot be slipped through with a wrapper shell, an absolute path, quoting tricks, or command substitution.

Commands that appear in both lists default to the denylist behavior. Any command that is in neither list falls back to the autonomy level you selected for the session.
Commands that appear in both the allowlist and denylist default to the denylist behavior. The blocklist always takes precedence over both. Any command that is in none of the lists falls back to the autonomy level you selected for the session.

### Example allow/deny configuration
### Example allow/deny/block configuration

```json
{
"commandAllowlist": ["ls", "pwd", "dir"],
"commandDenylist": ["rm -rf /", "mkfs", "shutdown"]
"commandDenylist": ["rm -rf /", "mkfs", "shutdown"],
"commandBlocklist": ["shutdown", "mkfs", "curl"]
}
```

Review and update these arrays periodically to match your workflow and security posture, especially when sharing configurations across teams.
Use `commandBlocklist` for commands that should be hard-stopped regardless of approvals; use `commandDenylist` for commands that are allowed only after explicit confirmation. Review and update these arrays periodically to match your workflow and security posture, especially when sharing configurations across teams.

## Session defaults

Expand Down
13 changes: 9 additions & 4 deletions docs/cli/user-guides/auto-run.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -31,17 +31,22 @@ Autonomy Level controls automatic approval, not which tools are available. Tool
- **Allow always** – Choosing an “always allow” option raises the current Autonomy Level to the level required by that prompt. Sandbox “allow always” options instead persist the allowed path or domain.
- **Spec approval** – When approving a Spec Mode plan, choose **Proceed with implementation** to keep the current Autonomy Level, or choose an available Low, Medium, or High option for implementation. Organization Maximum Autonomy Level can hide higher options.

## Command allowlists and denylists
## Command allowlists, denylists, and blocklists

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Mention blocklist in autonomy-level rules

The earlier Autonomy Level rules still describe auto-execution as being gated by risk level plus denylist/sandbox approval, but commandBlocklist is a hard stop with no approval path. Consider updating those earlier sentences/bullets to explicitly include blocklist as another reason a command will not run, even when risk <= Autonomy Level or the command is allowlisted.


Use `commandAllowlist` and `commandDenylist` in [Settings](/cli/configuration/settings) to encode command policy for your user profile, a project, a local project override, or a nested folder.
Use `commandAllowlist`, `commandDenylist`, and `commandBlocklist` in [Settings](/cli/configuration/settings) to encode command policy for your user profile, a project, a local project override, or a nested folder.

- Allowlist entries are treated as low-risk for the matching scope.
- Denylist entries always take precedence over allowlist entries.
- Commands not covered by either list fall back to the active Autonomy Level and command restrictions.
- Denylist entries always take precedence over allowlist entries. A denied command still runs if you explicitly approve it.
- Blocklist entries can never run: there is no approval prompt, and the block holds even under full autonomy, auto-run, or `--skip-permissions-unsafe`. Use it for commands that must be hard-stopped regardless of approvals.
- Commands not covered by any list fall back to the active Autonomy Level and command restrictions.
- Organization-managed settings have the highest priority. Local and project settings can add defaults for a repo or machine, but they cannot weaken organization command policy or raise autonomy above the organization maximum. See [Hierarchical Settings & Org Control](/enterprise/hierarchical-settings-and-org-control).

The built-in denylist covers common destructive patterns such as filesystem wipes, disk formatting, shutdown commands, fork bombs, and broad permission or ownership changes. Add project-specific commands when your repo has additional dangerous scripts or deployment paths.

<Warning>
Because the blocklist cannot be bypassed by approval, it is the strongest control available. droid resolves the actual program being invoked before matching, so a blocked command cannot be slipped through with a wrapper shell (for example `bash -c "…"`), an absolute path, quoting tricks, or command substitution.
</Warning>

## Change the level

- Press `Ctrl+L` to cycle `Off → Low → Medium → High → Off`. Organization policy can cap the highest available level.
Expand Down
7 changes: 6 additions & 1 deletion docs/enterprise/hierarchical-settings-and-org-control.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,11 @@ Below is the full schema for org-managed settings. These are configured by org a
</ResponseField>

<ResponseField name="commandDenylist" type="string[]">
Shell command patterns that are always denied (accumulated across levels).
Shell command patterns that are always denied (accumulated across levels). A denied command still runs if the user explicitly approves it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Reword commandDenylist from “always denied” to “confirm-required”

The schema currently says commands are “always denied” but then immediately notes they can still run if explicitly approved, which reads contradictory and blurs the line with commandBlocklist. Consider wording consistent with the CLI docs (for example, “always require confirmation; can run if explicitly approved”) to avoid implying a hard block.

</ResponseField>

<ResponseField name="commandBlocklist" type="string[]">

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Add missing wikiCloudSync to the “full schema”

This page states the <ResponseField> list is the full org-managed settings schema, but wikiCloudSync is referenced later on the same page and appears in the JP schema while the EN schema omits it. Add a <ResponseField name="wikiCloudSync" type="boolean">…</ResponseField> (near cloudSessionSync) so the EN schema is complete and consistent.

Shell command patterns that can never run (accumulated across levels). Unlike the denylist, blocked commands have no approval path: the block holds even under full autonomy, auto-run, or `--skip-permissions-unsafe`. droid resolves the actual program being invoked before matching, so a blocked command cannot be bypassed with a wrapper shell, an absolute path, quoting tricks, or command substitution. Use this for organization-mandated hard stops.
</ResponseField>

<ResponseField name="customModels" type="object[]">
Expand Down Expand Up @@ -418,6 +422,7 @@ Again, users cannot override these rules; they can only choose safer personal de
"ideAutoConnect": true,
"commandAllowlist": ["npm *", "yarn *", "pnpm *", "make *"],
"commandDenylist": ["rm -rf /", "sudo *"],
"commandBlocklist": ["shutdown", "mkfs", "curl"],
"customModels": [
{
"model": "my-internal-model",
Expand Down
17 changes: 12 additions & 5 deletions docs/jp/cli/configuration/settings.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,7 @@ droidの設定を行うには:
| `soundFocusMode` | `always`, `focused`, `unfocused` | `always` | 音声通知を再生するタイミング。 |
| `commandAllowlist` | コマンドの配列 | 安全なデフォルトが提供 | 追加確認なしで実行されるコマンド。 |
| `commandDenylist` | コマンドの配列 | 制限的なデフォルトが提供 | 常に確認が必要なコマンド。 |
| `commandBlocklist` | コマンドの配列 | `[]`(なし) | 承認をスキップしても絶対に実行されないコマンド。 |
| `includeCoAuthoredByDroid` | `true`, `false` | `true` | コミットにDroidの共同作成者トレーラーを自動追加します。 |
| `enableDroidShield` | `true`, `false` | `true` | シークレットスキャンとgitガードレールを有効にします。 |
| `hooksDisabled` | `true`, `false` | `false` | 全てのフックの実行をグローバルに無効にします。 |
Expand Down Expand Up @@ -133,16 +134,17 @@ droidイベントの音声フィードバックを設定します:
- **`false`** – IDEターミナル内での実行時のみ自動接続(デフォルト)
- **`true`** – 任意のターミナルからIDEに自動接続

## コマンド許可リストと拒否リスト
## コマンド許可リスト、拒否リスト、ブロックリスト

これらの設定を使用して、droidが自動実行できるコマンドと絶対に実行してはいけないコマンドを制御します:

- **`commandAllowlist`** – この配列内のコマンドは安全として扱われ、自律プロンプトに関係なく追加確認なしで実行されます。頻繁に使用する低リスクユーティリティのみを含めてください(例:`ls`、`pwd`、`dir`)。
- **`commandDenylist`** – この配列内のコマンドは常に確認が必要で、破壊的または危険なため通常ブロックされます(例:再帰的`rm`、`mkfs`、特権システム操作)。
- **`commandDenylist`** – この配列内のコマンドは常に確認が必要で、破壊的または危険なため通常ブロックされます(例:再帰的`rm`、`mkfs`、特権システム操作)。拒否されたコマンドでも、明示的に承認すれば実行できます。
- **`commandBlocklist`** – この配列内のコマンドは**絶対に**実行されません。拒否リストとは異なり、承認のプロンプトも承認する手段もありません。完全自律、自動実行、`--skip-permissions-unsafe`のいずれの場合でもブロックが適用されます。droidは実際に呼び出されるプログラムを解決してから照合するため、ラッパーシェル、絶対パス、クォートのトリック、コマンド置換でブロックを回避することはできません。

両方のリストに登場するコマンドは、拒否リストの動作がデフォルトとなります。どちらのリストにもないコマンドは、セッションで選択した自律レベルにフォールバックします。
許可リストと拒否リストの両方に登場するコマンドは、拒否リストの動作がデフォルトとなります。ブロックリストは常に両者より優先されます。いずれのリストにもないコマンドは、セッションで選択した自律レベルにフォールバックします。

### 許可/拒否設定例
### 許可/拒否/ブロック設定例
```json
{
"commandAllowlist": [
Expand All @@ -154,10 +156,15 @@ droidイベントの音声フィードバックを設定します:
"rm -rf /",
"mkfs",
"shutdown"
],
"commandBlocklist": [
"shutdown",
"mkfs",
"curl"
]
}
```
これらの配列を定期的に見直し更新して、ワークフローとセキュリティ体制に合わせてください。特にチーム間で設定を共有する場合は重要です。
承認に関係なくハードストップすべきコマンドには`commandBlocklist`を、明示的な確認後にのみ許可するコマンドには`commandDenylist`を使用してください。これらの配列を定期的に見直し更新して、ワークフローとセキュリティ体制に合わせてください。特にチーム間で設定を共有する場合は重要です。

## セッションデフォルト

Expand Down
13 changes: 9 additions & 4 deletions docs/jp/cli/user-guides/auto-run.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -31,17 +31,22 @@ ExecuteコマンドとMCPツールにはリスクレベル(`low`、`medium`、
- **常に許可** – 「常に許可」を選ぶと、そのプロンプトに必要なレベルまで現在の自律レベルが引き上げられます。サンドボックスの「常に許可」オプションは、代わりに許可されたパスやドメインを永続化します。
- **仕様承認** – Spec Modeのプランを承認するときは、現在の自律レベルを維持する**実装を進める**を選ぶか、実装用に利用可能なLow、Medium、Highを選択します。組織の最大自律レベルによっては、より高い選択肢が表示されない場合があります。

## コマンドallowlistとdenylist
## コマンドallowlist、denylist、blocklist

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] JP autonomy rules omit blocklist

In the JP guide, the “レベルを選ぶ” sentence and the allowlist bullet still mention only denylist/sandbox as exceptions for automatic execution, but commandBlocklist is an unconditional hard stop. Update those earlier lines to include blocklist so the described behavior matches what is documented below (blocklisted commands never run regardless of autonomy level or allowlist).


ユーザープロファイル、プロジェクト、ローカルのプロジェクト上書き、またはネストされたフォルダごとのコマンドポリシーを定義するには、[設定](/jp/cli/configuration/settings)の`commandAllowlist``commandDenylist`を使用します。
ユーザープロファイル、プロジェクト、ローカルのプロジェクト上書き、またはネストされたフォルダごとのコマンドポリシーを定義するには、[設定](/jp/cli/configuration/settings)の`commandAllowlist``commandDenylist`、`commandBlocklist`を使用します。

- allowlistのエントリは、そのスコープでは低リスクとして扱われます。
- denylistのエントリは、常にallowlistより優先されます。
- どちらのリストにも含まれないコマンドは、現在の自律レベルとコマンド制限に従います。
- denylistのエントリは、常にallowlistより優先されます。拒否されたコマンドでも、明示的に承認すれば実行できます。
- blocklistのエントリは絶対に実行されません。承認のプロンプトはなく、完全自律、自動実行、`--skip-permissions-unsafe`のいずれの場合でもブロックが適用されます。承認に関係なくハードストップすべきコマンドに使用してください。
- いずれのリストにも含まれないコマンドは、現在の自律レベルとコマンド制限に従います。
- 組織管理の設定が最優先されます。ローカル設定やプロジェクト設定でリポジトリやマシン向けのデフォルトを追加できますが、組織のコマンドポリシーを弱めたり、組織の最大値を超えて自律レベルを上げたりすることはできません。詳細は[階層設定と組織管理](/jp/enterprise/hierarchical-settings-and-org-control)を参照してください。

組み込みのdenylistには、ファイルシステムの消去、ディスク初期化、シャットダウンコマンド、fork bomb、広範な権限・所有者変更など、一般的な破壊的パターンが含まれます。リポジトリに追加の危険なスクリプトやデプロイ経路がある場合は、プロジェクト固有のコマンドを追加してください。

<Warning>
blocklistは承認では回避できないため、利用可能な最も強力な制御です。droidは照合前に実際に呼び出されるプログラムを解決するため、ラッパーシェル(例:`bash -c "…"`)、絶対パス、クォートのトリック、コマンド置換でブロックされたコマンドを回避することはできません。
</Warning>

## レベルを変更する

- `Ctrl+L`で`Off → Low → Medium → High → Off`の順に切り替えます。組織ポリシーで利用可能な最高レベルが制限される場合があります。
Expand Down
7 changes: 6 additions & 1 deletion docs/jp/enterprise/hierarchical-settings-and-org-control.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,11 @@ User → ~/.factory/
</ResponseField>

<ResponseField name="commandDenylist" type="string[]">
常に拒否されるシェルコマンドパターン(レベル間で累積)
常に拒否されるシェルコマンドパターン(レベル間で累積)。拒否されたコマンドでも、ユーザーが明示的に承認すれば実行できます。

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] JP commandDenylist wording is easy to misread as a hard block

In the JP schema, commandDenylist is described as “常に拒否される…(ただし明示的に承認すれば実行可)”, which can be confusing given commandBlocklist is the true hard stop. Align the wording with the intended semantics (“常に確認が必要…明示的に承認すれば実行可”) so denylist vs blocklist stays unambiguous.

</ResponseField>

<ResponseField name="commandBlocklist" type="string[]">
絶対に実行されないシェルコマンドパターン(レベル間で累積)。拒否リストとは異なり、ブロックされたコマンドには承認の手段がありません。完全自律、自動実行、`--skip-permissions-unsafe`のいずれの場合でもブロックが適用されます。droidは照合前に実際に呼び出されるプログラムを解決するため、ラッパーシェル、絶対パス、クォートのトリック、コマンド置換で回避することはできません。組織が義務付けるハードストップに使用してください。
</ResponseField>

<ResponseField name="customModels" type="object[]">
Expand Down Expand Up @@ -399,6 +403,7 @@ Factoryは、従来の「上書き」動作ではなく、**拡張のみ**のセ
"ideAutoConnect": true,
"commandAllowlist": ["npm *", "yarn *", "pnpm *", "make *"],
"commandDenylist": ["rm -rf /", "sudo *"],
"commandBlocklist": ["shutdown", "mkfs", "curl"],
"customModels": [
{
"model": "my-internal-model",
Expand Down
Loading