Permissions

Qoder CLI checks each tool call before it runs. The permission result is always one of three outcomes:

allow: run the tool immediately.
ask: show a confirmation prompt in interactive sessions.
deny: block the tool call.

Permissions apply to file reads and edits, Bash commands, web fetches, MCP tools, subagents, and other built-in tools.

Permission Modes

Use --permission-mode to choose the default behavior for a session.

qodercli --permission-mode default
qodercli --permission-mode accept_edits
qodercli --permission-mode plan
qodercli --permission-mode auto

Mode	Best for	Behavior
`default`	Normal interactive work	Safe reads and internal actions can run automatically. Sensitive actions ask for confirmation.
`accept_edits`	Routine coding tasks	Automatically approves safe file edits inside the working directories. Shell commands, external actions, and sensitive paths still go through normal checks.
`plan`	Review, investigation, and planning	Keeps the session planning-oriented. Qoder can read and reason about the project, while writes remain approval-bound except for plan files and explicit rules.
`auto`	Autonomous runs with no prompts	Returns allow or deny without prompting. Safe read tools and safe workspace edits can be approved automatically; risky actions are denied or sent through the classifier when available.
`bypass_permissions`	Trusted local experiments only	Skips most approval prompts. Some safety checks, dangerous shell commands, and user-interaction actions can still ask or deny.
`dont_ask`	Headless flows that must not prompt	Never prompts. Any action that would ask is denied.

You can also pass compatible camelCase values such as acceptEdits, bypassPermissions, and dontAsk. Non-default modes only apply in trusted folders. If the current folder is not trusted, Qoder falls back to default. bypass_permissions can also be disabled by security settings.

Set a Default Mode

For persistent defaults, configure general.defaultPermissionMode in settings.

{
  "general": {
    "defaultPermissionMode": "accept_edits"
  }
}

Use default, accept_edits, plan, or auto in settings. Start with --permission-mode bypass_permissions when you intentionally need bypass mode for a trusted session.

Bypass Mode

--dangerously-skip-permissions is an alias for --permission-mode bypass_permissions.

qodercli --dangerously-skip-permissions

Use this only when you trust the workspace and the task. It is not an unconditional allowlist for every operation.

How Decisions Are Made

Qoder evaluates permissions in a fixed order:

deny rules are checked first.
In auto mode, Qoder must resolve the action to allow or deny; it does not open approval prompts.
ask rules and tool-specific checks run before broad allow rules.
Safety checks can still interrupt broad rules or bypass mode.
Tool-wide allow rules and mode-based allow behavior are applied.
If a result is still ask in a non-interactive session, it becomes deny.

This means a broad allow rule is not enough to make every action silent. For example, a dangerous shell command can still require confirmation, and suspicious paths can still be blocked.

Configure Rules

Persistent rules live in settings files:

~/.qoder/settings.json
${project}/.qoder/settings.json
${project}/.qoder/settings.local.json

settings.local.json is intended for machine-local approvals and is usually gitignored. Team-wide rules normally belong in project settings. Rules are grouped under allow, ask, and deny.

{
  "permissions": {
    "allow": [
      "Read(/src/**)",
      "Edit(/src/**)",
      "Bash(npm run test:*)"
    ],
    "ask": [
      "Bash(npm publish:*)",
      "WebFetch"
    ],
    "deny": [
      "Read(*.pem)",
      "Bash(rm -rf:*)"
    ]
  }
}

If an organization policy enables managed-only permission rules, only policy-managed rules are used.

Rule Syntax

Rules use one of these forms:

Form	Meaning
`ToolName`	Applies to the whole tool.
`ToolName(content)`	Applies to a specific path, command, agent type, or another tool-specific value when that tool supports content rules.
`*`	Applies to all tools at the tool level.

Use canonical tool names such as Read, Edit, Write, Bash, Grep, Glob, WebFetch, WebSearch, Agent, and MCP names like mcp__github__create_issue. If the content contains parentheses, escape them:

{
  "permissions": {
    "allow": [
      "Bash(python -c \"print\\(1\\)\")"
    ]
  }
}

ToolName(*) is treated as a tool-wide rule, the same as ToolName.

File Access Rules

Qoder treats the current workspace as the main working directory. You can add more trusted working directories with --add-dir, the /add-dir command, or permissions.additionalDirectories.

qodercli --add-dir ../shared

{
  "permissions": {
    "additionalDirectories": ["../shared"]
  }
}

Path-scoped read rules use Read(...). Path-scoped write rules use Edit(...); they cover file editing and writing checks for Edit, Write, and NotebookEdit. An Edit(...) allow rule also implies read permission for the same path. File patterns use gitignore-style matching.

Pattern	Meaning
`/src/**`	Source-rooted path. In project or local settings, this is relative to the project root. In user settings, it is relative to the home directory.
`~/Documents/**`	Home-directory path.
`//tmp/data/**`	Absolute filesystem path from `/`. Use the double slash for absolute paths.
`*.secret`	Rootless filename pattern that can match from any location.

Examples:

{
  "permissions": {
    "allow": [
      "Read(/src/**)",
      "Edit(/src/**)",
      "Read(~/Documents/specs/**)"
    ],
    "ask": [
      "Edit(/package.json)",
      "Read(~/Downloads/**)"
    ],
    "deny": [
      "Read(*.pem)",
      "Edit(/.git/**)",
      "Edit(//etc/**)"
    ]
  }
}

Reads inside working directories are allowed by default unless a deny or ask rule applies. Writes inside working directories are auto-approved in accept_edits and auto when the path is safe. Some paths are protected because editing them can change execution, credentials, or tool behavior. Examples include .git, .vscode, .idea, .husky, most .qoder configuration files, shell startup files such as .bashrc and .zshrc, Git config files, .mcp.json, and .ripgreprc. In normal interactive modes these paths require explicit approval; in auto mode they are denied instead of prompting.

Bash Rules

Bash(...) rules can match exact commands, command prefixes, or wildcard patterns.

Rule	Matches
`Bash(npm run build)`	Exactly `npm run build`.
`Bash(npm run test:*)`	`npm run test` and commands beginning with `npm run test` .
`Bash(git log *)`	Glob-style wildcard matching.
`Bash(git status)`	Exactly `git status`.

Examples:

{
  "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 matching is conservative:

deny and ask rules can see through common wrappers and environment prefixes, so a rule like Bash(rm -rf:*) still catches wrapped destructive commands.
Prefix and wildcard allow rules do not silently approve compound commands unless every top-level command segment is independently allowed.
Some provably read-only shell commands can be allowed automatically after deny, ask, and path checks run.
Dangerous commands, such as destructive deletes or force pushes, can still force confirmation even when a broad allow rule exists. In auto mode, dangerous shell commands are denied.

Avoid broad rules such as Bash or Bash(*) unless you fully trust the session. They are effectively tool-wide shell approval outside of the remaining safety checks.

Web and MCP Rules

Web tools can be controlled at the tool level. Use ask when every web fetch should require confirmation, or deny when web access should be blocked for a session or project.

{
  "permissions": {
    "ask": [
      "WebFetch"
    ],
    "deny": [
      "WebSearch"
    ]
  }
}

MCP tools use fully qualified names:

mcp__<server>__<tool>

Supported MCP patterns include:

Rule	Meaning
`mcp__github__create_issue`	One MCP tool.
`mcp__github__*`	All tools from the `github` MCP server.
`mcp__github`	All tools from the `github` MCP server.
`mcp__*`	All MCP tools.

Example:

{
  "permissions": {
    "allow": [
      "mcp__context7__*"
    ],
    "ask": [
      "mcp__github__create_issue"
    ]
  }
}

MCP server configs can also set alwaysAllow for tools from that server. If you only want selected MCP servers to be active for a run, use --allowed-mcp-server-names.

qodercli --allowed-mcp-server-names context7,github

Command-Line Overrides

Use command-line flags for one-off sessions:

qodercli --permission-mode accept_edits
qodercli --allowed-tools 'Read,Grep,Bash(git status)'
qodercli --disallowed-tools 'Bash(rm -rf:*),mcp__github__delete_repo'
qodercli --tools 'Read,Grep,Edit'

--allowed-tools and --disallowed-tools accept the same rule syntax as settings. --tools restricts the available built-in tool set; built-in tools not listed are denied for that run.

Non-Interactive Sessions

In print mode, --prompt, and other headless sessions, Qoder cannot show approval prompts. Any action that would normally return ask is denied unless you choose a mode or rule set that allows it. For automation:

Prefer narrow allow rules for the exact tools, paths, commands, and MCP servers required.
Use accept_edits when the automation should edit files inside trusted working directories.
Use dont_ask when you want a strict fail-closed run.
Use bypass_permissions only in a trusted environment where broad tool execution is intentional.

Get Started

User Guide

SDK

Cloud Agents

Permission Modes

Set a Default Mode

Bypass Mode

How Decisions Are Made

Configure Rules

Rule Syntax

File Access Rules

Bash Rules

Web and MCP Rules

Command-Line Overrides

Non-Interactive Sessions

Get Started

User Guide

SDK

Cloud Agents

Documentation Index

​Permission Modes

​Set a Default Mode

​Bypass Mode

​How Decisions Are Made

​Configure Rules

​Rule Syntax

​File Access Rules

​Bash Rules

​Web and MCP Rules

​Command-Line Overrides

​Non-Interactive Sessions

Permission Modes

Set a Default Mode

Bypass Mode

How Decisions Are Made

Configure Rules

Rule Syntax

File Access Rules

Bash Rules

Web and MCP Rules

Command-Line Overrides

Non-Interactive Sessions