docs(cli): document commandBlocklist hard command-rejection setting#1210
docs(cli): document commandBlocklist hard command-rejection setting#1210shashank-factory wants to merge 1 commit into
Conversation
Add the new commandBlocklist option (hard-blocked commands that can never run, even under full autonomy/auto-run/--skip-permissions-unsafe) alongside the existing allowlist/denylist docs: - cli/configuration/settings.mdx: settings table row, section rename, bullet, precedence note, and example JSON - cli/user-guides/auto-run.mdx: command-policy bullets + bypass-resistance warning - enterprise/hierarchical-settings-and-org-control.mdx: ResponseField + org example - mirrored all of the above in the jp/ counterparts
|
Droid finished @shashank-factory's task —— View job The new |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![factory-droid[bot]](https://avatars.githubusercontent.com/in/358017?s=60&v=4){kind=small}
| - **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 |
There was a problem hiding this comment.
[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.
| - **仕様承認** – Spec Modeのプランを承認するときは、現在の自律レベルを維持する**実装を進める**を選ぶか、実装用に利用可能なLow、Medium、Highを選択します。組織の最大自律レベルによっては、より高い選択肢が表示されない場合があります。 | ||
|
|
||
| ## コマンドallowlistとdenylist | ||
| ## コマンドallowlist、denylist、blocklist |
There was a problem hiding this comment.
[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).
| Shell command patterns that are always denied (accumulated across levels). A denied command still runs if the user explicitly approves it. | ||
| </ResponseField> | ||
|
|
||
| <ResponseField name="commandBlocklist" type="string[]"> |
There was a problem hiding this comment.
[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.
|
|
||
| <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. |
There was a problem hiding this comment.
[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 name="commandDenylist" type="string[]"> | ||
| 常に拒否されるシェルコマンドパターン（レベル間で累積） | ||
| 常に拒否されるシェルコマンドパターン（レベル間で累積）。拒否されたコマンドでも、ユーザーが明示的に承認すれば実行できます。 |
There was a problem hiding this comment.
[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.
1 participant
Summary
Documents the new
commandBlocklistCLI setting (hard command rejection) that ships in the factory-mono PR forcli-791. Blocklisted commands can never run: there is no approval prompt and the block holds even under full autonomy, auto-run, or--skip-permissions-unsafe. Enforcement resolves the actual program being invoked, so wrapper shells, absolute paths, quoting tricks, and command substitution cannot bypass it.Changes
docs/cli/configuration/settings.mdx– new settings-table row, renamed "Command allowlist, denylist & blocklist" section,commandBlocklistbullet, precedence note (blocklist > deny/allow), and example JSON.docs/cli/user-guides/auto-run.mdx– command-policy bullets updated + a<Warning>explaining bypass resistance.docs/enterprise/hierarchical-settings-and-org-control.mdx–commandBlocklistResponseFieldin the org-managed settings schema + org example JSON.jp/counterparts.Notes
Paired with the implementation + review-remediation PR in
factory-mono(branchssharma/cli-791-add-hard-command-rejection-rules-without-approval). No behavior changes here; docs only.