Skip to main content
設定とセキュリティ

権限

権限モード

権限モードは Qoder がツール呼び出しをどのように処理するかを決定します。各モードは「自動化の度合い」と「セキュリティの緩さ」の 2 軸で異なる位置づけになります。
モード適用シナリオ動作
default通常のインタラクティブ利用安全な読み取りと内部アクションは自動実行。センシティブな操作は確認を要求します。
accept_edits日常的なコーディング作業ディレクトリ内の安全なファイル編集を自動承認。Shell コマンド、外部アクション、センシティブなパスは通常のチェックを通ります。
auto無人実行認可はエージェントが判断します。
bypass_permissions (YOLO)信頼できるローカル実験のみ承認プロンプトをスキップします。一部のパス形状に対する保護は有効なままです(「パス形状」を参照)。
dont_askプロンプト不可の headless フロー確認しません。本来確認が必要な操作はすべて拒否されます。

モードサイクル切り替え

インタラクティブセッションでは、Shift+Tab ですべての権限モード間を循環切り替えできます。Ctrl+Y で YOLO モードに直接ジャンプできます。

起動パラメータ

--permission-mode で現在のセッションのデフォルト動作を選択します:
qoder --permission-mode default
qoder --permission-mode accept_edits
qoder --permission-mode plan           # 旧バージョン互換:default + Plan ワークステートに入るに変換
qoder --permission-mode auto
qoder --permission-mode bypass_permissions
qoder --permission-mode yolo           # bypass_permissions と同等
qoder --permission-mode dont_ask

# ショートカット
qoder --yolo                         # --permission-mode bypass_permissions と同等
qoder --dangerously-skip-permissions # 同上
インタラクティブセッションでは、Ctrl+Y で素早く YOLO モードに切り替えることもできます。 複数の命名形式に対応しています(大文字小文字不問):
標準値 (snake_case)camelCaseエイリアス
accept_editsacceptEdits
bypass_permissionsbypassPermissionsyolo, YOLO
dont_askdontAsk
例:
# 以下はすべて同等です
qoder --permission-mode bypass_permissions
qoder --permission-mode bypassPermissions
qoder --permission-mode yolo
qoder --yolo
qoder --dangerously-skip-permissions
非 default モードは信頼済みディレクトリ内でのみ有効になります。現在のディレクトリが信頼されていない場合、Qoder は default にフォールバックします。

権限の判定方法

Qoder は各ツール呼び出しの前に権限チェックを行います。結果は常に 3 つのうちいずれかです:
  • allow: ツールを即座に実行します。
  • ask: 外部の確認が得られてから実行します。
  • deny: ツール呼び出しをブロックします。
権限はファイルの読み書き、Bash コマンド、Web fetch、MCP ツール、Subagent、その他の組み込みツールに適用されます。

判定順序

Qoder は固定順で権限を評価します:
  1. まず deny ルールを確認 — 一致すれば即座に拒否。
  2. ツール自身の安全チェック(危険コマンド検出、センシティブパス検出など)。
  3. ask ルール — 一致すれば確認が必要とマークします。
  4. ツールレベルの allow ルールとモード由来の自動許可動作。
  5. 最終結果がまだ ask の場合、ランタイム環境が消費方法を決定します。
広い allow ルールがあってもすべての操作が無音で実行されるわけではありません — 安全チェックと ask ルールの方が優先度が高いです。

異なる実行環境での ask の消費方法

実行環境ask の行き先説明
TUI(インタラクティブターミナル)確認プロンプトユーザーがターミナルで許可/拒否を選択します。
Headless-p/--prompt自動拒否人の対話がないため、askdeny になります。
SDK(stdio プロトコル)ホストに canUseTool コールバックを送信ホストプログラムが allow/deny を決定します。
ACP(IDE 統合)IDE に requestPermission RPC を送信IDE がプロンプト表示または自動決定します。
Headless モード(-p/--prompt)は権限モードと組み合わせ可能です:
# Headless + accept_edits:ファイル編集は自動通過、Bash は拒否
qoder -p "refactor the utils module" --permission-mode accept_edits

# Headless + bypass_permissions:すべて許可(信頼シナリオのみ)
qoder -p "run the migration" --yolo

# Headless + 精密 allow ルール:特定ツールのみ許可
qoder -p "check status" --allowed-tools 'Read,Bash(git status)'

権限設定

設定ソース(8 層優先度)

ルールは複数のソースからマージされ、優先度が低い順に:
ソース説明
1userSettings~/.qoder/settings.json(ユーザーグローバル)
2projectSettings<project>/.qoder/settings.json(プロジェクトレベル、チーム共有)
3localSettings<project>/.qoder/settings.local.json(マシンローカル、.gitignore に追加)
4flagSettings--settings <path> CLI 引数で指定する追加ファイル
5cliArg--allowed-tools / --disallowed-tools コマンドライン引数
6command/allow/deny セッション内コマンド
7sessionランタイム一時ルール(プロンプトで「今回のセッションで許可」)
高優先度ソースのルールが低優先度を上書きします。組織ポリシーが allowManagedPermissionRulesOnly を有効にしている場合、ポリシー管理ルールのみが使用されます。 各ソースの設定方法:
  • 層 1-3(settings ファイル):対応パスの JSON ファイルに permissions.allow / permissions.deny / permissions.ask 配列を記述します。settings.local.json はマシン固有の承認ルールに最適で、.gitignore に追加することを推奨します。
  • 層 4(flagSettings)qoder --settings ./custom-settings.json で追加の settings ファイルを指定します。標準 settings.json と同じ形式です。
  • 層 5(cliArg)--permission-mode--allowed-tools--disallowed-tools--tools 等のコマンドライン引数で設定。現在のセッションのみ有効。
  • 層 6(command):セッション中に /allow Bash(npm test)/deny WebFetch と入力。settings.local.json に永続化されます。
  • 層 7(session):プロンプトで「今回のセッションで許可」を選択した一時ルール。プロセス終了で失効。

モード設定

デフォルトモードの設定 — settings で general.defaultPermissionMode を設定:
{
  "general": {
    "defaultPermissionMode": "accept_edits"
  }
}
サポートされる値:
動作エイリアス
default每回承認を求める
accept_editsファイル編集を自動承認、Shell コマンドは確認が必要acceptEdits
plan読み取り専用モード(旧バージョン互換:default + Plan ワークステートに変換)
auto認可はエージェントが判断
bypass_permissions権限プロンプトをスキップ(YOLO)yolobypassPermissions
dont_ask非対話モード、承認が必要な操作は拒否dontAsk
大文字小文字を区別しません。すべてのエイリアスが使用可能です。 YOLO モードの無効化 — 組織管理者が bypass_permissions モードへの移行を防止できます:
{
  "security": {
    "disableYoloMode": true
  }
}
設定後、--yolo--permission-mode bypass_permissions、Ctrl+Y はすべて無効になり、Shift+Tab サイクルもこのモードをスキップします。Sub-agent が bypass を宣言した場合も acceptEdits に降格されます。 Plan モードの無効化 — Plan ワークフローが不要な場合:
{
  "general": {
    "plan": {
      "enabled": false
    }
  }
}
設定後、/plan コマンドは使用不可になり、--permission-mode plan は default にフォールバックし、EnterPlanMode/ExitPlanMode ツールは登録されません。 Auto モード分類器設定 — 自然言語ルールで AI 分類器の判断傾向をガイドできます:
{
  "autoMode": {
    "allow": [
      "running npm/yarn/pnpm scripts defined in package.json",
      "creating or editing test files"
    ],
    "soft_deny": [
      "deleting files outside the test directory",
      "modifying CI/CD configuration"
    ],
    "environment": [
      "This is a Node.js monorepo with pnpm workspaces",
      "The project uses Vitest for testing"
    ]
  }
}
フィールド目的
allow分類器が自動承認に傾く操作の説明
soft_deny分類器が拒否に傾く操作の説明
environment分類器に提供する環境コンテキスト情報
これらのルールはソフトガイダンスです — 分類器の prompt にリファレンスとして注入され、最終判断は AI 分類器が行います。セキュリティ上、autoMode 設定はあなた自身のグローバル settings からのみ読み取られます。ワークスペース配下のファイルは settings.local.json を含めて無視されます:ワークスペース内のファイルはチェックアウトと共に持ち込まれる可能性があり、分類器に allow エントリを追加できるリポジトリは auto モードを承認寄りに傾けられるためです。 ユーザーレベルの AGENTS.md も分類器のコンテキストに注入され、当該セッションの意図を判断する根拠として扱われます。読み取られるのはユーザーレベルのファイルのみです。その内容は意図を示すものであり、承認を与えるものではありません:安全ルールに反する操作は、当該ファイルが認めているように見えてもブロックされます。 分類器を経由せずに裁定される操作
  • 読み取り専用ツール(ファイル読み取り、検索、glob)はツール名で承認されます。対象パスは評価されないため、ワークスペース外のパスも承認されます。
  • ワークスペース内、および /add-dir で追加したディレクトリ内の書き込みと編集は、直接承認されます。
  • それ以外の操作はすべて分類器に提出されます。上記ディレクトリ外への書き込みも含みます。
分類器は 2 段構成です。第 1 段は高速な判定で、承認のみが可能です。承認されなかった操作は第 2 段に提出され、ブロックと判定できるのは第 2 段のみです。したがってツール呼び出しごとに裁定の所要時間は異なります。 サーキットブレーカー auto モードでは、ツール呼び出しの認可はエージェントが判断し、個別の確認は行いません。ブロック判定が連続して上限に達するとサーキットブレーカーが作動します:次の操作は認可ダイアログに切り替わり、上限の警告と直近のブロック理由が示されます。モード自体は引き続き利用でき、一度承認されるとカウントは 0 に戻ります。 auto モードで権限判定が認可ダイアログを生じさせるのは、このサーキットブレーカーのみです。分類器に到達できない、または有効な判定が返らない場合、当該操作はダイアログではなく拒否として扱われます。メッセージにはこれが操作に対する安全判定ではないことが示され、同じ操作を再試行できます。読み取り専用ツールは影響を受けません。利用可能な分類器モデルがない場合は auto モードへの切り替えを拒否します。 なお、ユーザー入力を必要とするツール(AskUserQuestion など)と Plan の開始・終了は常に確認を求めます。セッションが長くなり分類器が全体のコンテキストを読み取れない場合も確認に切り替わります。これらはいずれも権限判定の結果ではありません。

権限ルール設定

ルールは allowaskdeny に分類されます:
{
  "permissions": {
    "allow": [
      "Read(/src/**)",
      "Edit(/src/**)",
      "Bash(npm run test:*)"
    ],
    "ask": [
      "Bash(npm publish:*)",
      "WebFetch"
    ],
    "deny": [
      "Read(*.pem)",
      "Bash(rm -rf:*)"
    ]
  }
}

ルール構文

形式意味
ToolNameツール全体に適用します。
ToolName(content)特定のパス、コマンド、agent type、またはそのツール固有の値に適用します。
*すべてのツールに一致します。
正規ツール名を使用してください:ReadEditWriteBashGrepGlobWebFetchWebSearchAgent、および mcp__github__create_issue のような MCP ツール名。 内容に括弧が含まれる場合はエスケープします:
{
  "permissions": {
    "allow": [
      "Bash(python -c \"print\\(1\\)\")"
    ]
  }
}
ToolName(*)ToolName(ツールレベルルール)と同等です。

コマンドラインでの上書き

qoder --allowed-tools 'Read,Grep,Bash(git status)'
qoder --disallowed-tools 'Bash(rm -rf:*),mcp__github__delete_repo'
qoder --tools 'Read,Grep,Edit'
--allowed-tools--disallowed-tools は settings と同じルール構文を使います。--tools は現在の実行で利用可能な組み込みツールセットを制限します(一覧にないツールは拒否されます)。

信頼ディレクトリ

Qoder は起動時のカレントワーキングディレクトリ(CWD)をメイン信頼ディレクトリとして扱います。信頼ディレクトリ内では:
  • ファイル読み取りはデフォルトで許可
  • ファイル書き込みは accept_editsauto モードで自動承認可能
  • 非 default 権限モード(auto、bypass 等)が有効になる
現在のディレクトリが信頼されていない場合、Qoder は default モードに強制フォールバックします。

信頼範囲の拡張

--add-dir/add-dir コマンド、または permissions.additionalDirectories で追加の信頼済み作業ディレクトリを指定します:
qoder --add-dir ../shared
{
  "permissions": {
    "additionalDirectories": ["../shared"]
  }
}
グローバル settings で permissions.trustDirectories を設定して、よく使うディレクトリを永続的に信頼することもできます。

保護パス

一部のパスは、編集すると実行動作、認証情報、ツール動作が変わる可能性があるため保護されています。例:.git.vscode.idea.husky、多くの .qoder 設定ファイル、.bashrc/.zshrc 等の shell 起動ファイル、Git 設定、.mcp.json.ripgreprc。通常のインタラクティブモードでは明示的な承認が必要です。

パス形状

一部のパス表記は、ローカルファイルシステム外のリソースに到達したり、パス比較を回避したりします。これらはルールとは別に、2 つの独立した軸で扱われます。
  • ネットワーク上の場所 —— 区切り文字 2 つで始まるパス(\server\share//server/share)、拡張 UNC 形式(\?\UNC\server\share)、WebDAV 表記、および /net/<host>/… オートマウントパス。読み取り・検索・書き込み・Shell アクセスはいずれも拒否されます。
  • ローカルマウント —— \wsl$\…\wsl.localhost\…\?\C:\…\?\Volume{…}\… はローカルストレージを指し、通常のルールに従います。\127.0.0.1\share のようなループバックホストはネットワーク上の場所として扱われます。
  • 回避されやすい表記 —— 代替データストリーム(file.txt:stream)、8.3 短縮名(PROGRA~1)、デバイスパス(\.\…)、末尾のドットや空白、3 つ以上連続するドット、予約デバイス名(CONNULCOM1)には明示的な承認が必要です。

ファイルアクセスルール

パス付き読み取りルールは Read(...) を使います。パス付き書き込みルールは Edit(...) を使い、EditWriteNotebookEdit のファイル書き込みチェックをカバーします。同じパスの Edit(...) allow ルールは読み取り権限も暗黙に許可します。 ファイルルールは gitignore 形式で一致します。
パターン意味
/src/**ルールソースのルートディレクトリ基準。project/local settings ではプロジェクトルート基準、user settings では home ディレクトリ基準。
~/Documents/**home ディレクトリ基準のパス。
//tmp/data/**システムの / から始まる絶対パス。絶対パスにはダブルスラッシュを使います。ルールパターンの先頭の // は「ファイルシステムのルートからの絶対パス」を意味し、上記のネットワーク上の場所の扱いとは無関係です。
*.secretルートなしのファイル名パターン。任意の場所で一致可能。
例:
{
  "permissions": {
    "allow": [
      "Read(/src/**)",
      "Edit(/src/**)",
      "Read(~/Documents/specs/**)"
    ],
    "ask": [
      "Edit(/package.json)",
      "Read(~/Downloads/**)"
    ],
    "deny": [
      "Read(*.pem)",
      "Edit(/.git/**)",
      "Edit(//etc/**)"
    ]
  }
}

Bash ルール

Bash(...) ルールは完全一致コマンド、コマンド接頭辞、またはワイルドカードパターンに一致できます。
ルール一致内容
Bash(npm run build)npm run build に完全一致。
Bash(npm run test:*)npm run test および npm run test で始まるコマンドに一致。
Bash(git log *)glob 形式のワイルドカードで一致。
Bash(git status)git status に完全一致。
例:
{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git log:*)",
      "Bash(npm run test:*)"
    ],
    "ask": [
      "Bash(npm publish:*)",
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)"
    ]
  }
}
Shell の一致は保守的です:
  • denyask ルールは一般的な wrapper や環境変数プレフィックスを見通すため、Bash(rm -rf:*) はラップされた破壊的コマンドも捕捉できます。
  • 接頭辞やワイルドカードの allow ルールは、各トップレベルコマンド片が独立して許可されない限り、複合コマンドを無音で承認しません。
  • 一部の明確に読み取り専用と判断できる shell コマンドは、deny、ask、パスチェックの後で自動許可されます。
  • 破壊的削除や force push などの危険なコマンドは、広い allow ルールがあっても確認を強制できます。
セッションを完全に信頼する場合を除き、BashBash(*) のような広いルールは避けてください。

Web と MCP のルール

Web ツールはツールレベルのルールで制御できます。すべての web fetch で確認を求める場合は ask、セッションまたはプロジェクトで web access をブロックする場合は deny を使います。
{
  "permissions": {
    "ask": [
      "WebFetch"
    ],
    "deny": [
      "WebSearch"
    ]
  }
}
MCP ツールは完全修飾名を使います:
mcp__<server>__<tool>
対応する MCP パターン:
ルール意味
mcp__github__create_issue1 つの MCP ツール。
mcp__github__*github MCP server の全ツール。
mcp__githubgithub MCP server の全ツール。
mcp__*すべての MCP ツール。
例:
{
  "permissions": {
    "allow": [
      "mcp__context7__*"
    ],
    "ask": [
      "mcp__github__create_issue"
    ]
  }
}
MCP server 設定では、その server のツールに対して alwaysAllow も設定できます。1 回の実行で有効にする MCP server を限定したい場合は --allowed-mcp-server-names を使います。
qoder --allowed-mcp-server-names context7,github

Hook と権限

Qoder の Hook システムは権限判定パイプラインに 2 つのインジェクションポイントを持ち、カスタムスクリプトでツールの許可/拒否動作に影響を与えることができます。

権限に影響する Hook イベント

Hook イベントトリガータイミング権限への影響
PreToolUseツール実行前(権限チェックフェーズ)`permissionDecision: "allow"
PermissionRequestパイプラインが ask を出力した後、プロンプト前decision.behaviorallow または deny として返し、ユーザー対話を代替可能
その他の Hook イベント(PostToolUseSessionStartStop 等)は権限判定に関与しません。

PreToolUse Hook

ツール実行前にトリガーされます。Hook スクリプトはツール名とパラメータを検査し、権限判定を返すことができます:
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python ./scripts/check-bash-command.py"
          }
        ]
      }
    ]
  }
}
Hook スクリプトは stdin で JSON 入力(tool_nametool_inputsession_id 等を含む)を受け取り、stdout で JSON 結果を出力します:
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Command blocked by security policy"
  }
}
permissionDecision の値:
  • "allow": 権限パイプラインをスキップし、直接承認
  • "deny": 権限パイプラインをスキップし、直接拒否
  • "ask": 通常の権限パイプラインを続行(デフォルト動作)

PermissionRequest Hook

権限パイプラインが ask を出力した後、プロンプト/コールバックの前にトリガーされます。自動化承認システムや外部通知(Slack/メールアラートなど)に適しています:
{
  "hooks": {
    "PermissionRequest": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "node ./scripts/auto-approve-safe-ops.js"
          }
        ]
      }
    ]
  }
}
出力形式:
{
  "hookSpecificOutput": {
    "hookEventName": "PermissionRequest",
    "decision": {
      "behavior": "allow",
      "updatedInput": {},
      "updatedPermissions": []
    }
  }
}

Hook と権限モードの優先度

Hook の権限判定は権限モードよりも高い優先度を持ちます — bypass_permissions モードであっても、PreToolUse Hook が deny を返せば実行はブロックされます。これにより組織レベルのセキュリティポリシーに対してバイパス不可能な遮断能力を提供します。 実行順序:
  1. Hook PreToolUse → allow/deny を返した場合ショートサーキット
  2. 権限パイプライン(ルール + モード + 安全チェック)
  3. 結果が ask の場合 → Hook PermissionRequest → allow/deny を返した場合ショートサーキット
  4. 最終的にランタイム環境が ask を消費(プロンプト/拒否/コールバック)
Qoder CLI を使用する