Permission Mode

Download

Focus Mode

Font Size

Last updated: 2026-09-30 18:41:47

AI-Translated & Reviewed

Overview
Control whether CodeBuddy should automatically continue, ask the user, or directly deny before it edits files, runs commands, accesses the network, or invokes other high-risk tools. The permission mode determines the session rhythm, not the entire logic of the permission system.
First Understand: Permission Mode Is Just One Layer in the Permission System
For each tool invocation, CodeBuddy does not simply check the current mode. It also goes through the following in sequence:
1. Special handling for hooks / interactive tools
2. deny rules
3. Trusted allow rules
4. Command security check (interactive only)
5. ask rules
6. bypassPermissions short-circuit
7. Untrusted allow rules
8. The baseline policy of the current permission mode
9. Non-interactive fallback and final resolution of auto / dontAsk
Therefore:
deny always takes precedence over mode.
allow / ask rules change the actual behavior of mode.
auto only takes over actions that would still end with an ask.
dontAsk does not mean "more permissive". Instead, it means "do not prompt and directly deny actions that are not pre-approved".
bypassPermissions is not an absolute unconditional pass either: preceding deny / ask rules and interactive dangerous command checks can still block it.
For the complete evaluation order of permission rules, see Permission Rules.
Available Modes
CodeBuddy Code provides the following permission modes. Most of these modes can be switched or specified directly in the CLI, while some are used for IDE integration and subagent scenarios.
Modes That Users Can Switch Manually
Mode
What Can Run Without Prompting
Scenario
default
Read tools in trusted directories
Default; suitable for sensitive workloads / the onboarding period
acceptEdits
Read + Edit tools in trusted directories
Review with git diff while making changes.
auto
Actions that would originally trigger an ask are handed to the classifier to determine allow / deny.
Reduce interruptions while maintaining security boundaries.
dontAsk
Only pre-approved actions continue to run; all others are denied directly without asking.
Non-interactive automation / fixed allowlist agent
plan
Delegates to the mode used before plan is entered (default = default); additionally allows writing to the session plan file.
Understand the code before making changes and then decide.
bypassPermissions
Skip most approvals.
Only for sandbox containers / VMs / offline dev containers
delegate
Only coordination tools (such as Agent / TaskCreate / SendMessage / team management) are available; implementation tools are blocked.
The main agent only decomposes and dispatches tasks, delegating execution to subagents.
Programmatic/Integration Mode (Not in the Shift+Tab Cycle)
Mode
When It Occurs
fullAccess
The IDE client passes it in through the protocol; semantically, it is close to the global allow-all of bypassPermissions.
work
Passed in by the IDE client. Read is directly allowed without checking trusted directories, Edit always prompts for confirmation, and for Bash, only safe commands are directly allowed while others prompt for confirmation.
ignore
Effective only in subagent / teammate scenarios. It means to use the main session's mode and not be overridden by the subagent's own frontmatter. Not used by the main session.
Note:
From an implementation perspective, auto, dontAsk, plan, and bypassPermissions can all be specified through the CLI or settings. delegate is mainly switched through Shift+Tab within a session.
How to Switch Permission Modes
Switch During a Session: Shift+Tab
In the CLI, press Shift+Tab to cycle through the following modes:
default → bypassPermissions → acceptEdits → auto (when available) → plan → delegate → default → ...
Note:
auto appears in the cycle only when it is available in the current environment.
dontAsk is not in the keyboard cycle and can only be entered through CLI, settings, or SDK / IDE control signals.
On Windows, both Shift+Tab and Alt+M can be triggered (Alt+M is a compatibility alias).
You can customize keyboard shortcuts through ~/.codebuddy/keybindings.json.
Status Bar Indicator
After switching, the current mode is displayed below the input area:
Mode
Copy
Description
default
Not displayed
The default mode does not occupy extra space.
bypassPermissions
⏵⏵ bypass permissions on (shift+tab to cycle)
Can switch back to other modes cyclically.
acceptEdits
⏵⏵ accept edits on (shift+tab to cycle)
Can switch back to other modes cyclically.
auto
⏵⏵ auto mode on (shift+tab to cycle)
Appears only when available.
dontAsk
⏵⏵ don't ask on
Not in the cycle chain, so there is no cycle hint.
plan
⏸ plan mode on (shift+tab to cycle)
Indicates that the current mode is plan mode.
plan + preceding mode
⏸ plan + accept edits (shift+tab to cycle), and so on
Displays the baseline mode inherited before plan mode.
delegate
⇢ delegate mode on (shift+tab to cycle)
The main agent only performs coordination.
Specify at Startup: --permission-mode
codebuddy --permission-mode default
codebuddy --permission-mode acceptEdits
codebuddy --permission-mode auto
codebuddy --permission-mode dontAsk
codebuddy --permission-mode plan
codebuddy --permission-mode bypassPermissions
--permission-mode officially supports these 6 literal values. Other modes (delegate / work / fullAccess / ignore) cannot be used as standard CLI startup parameters.
It is also available in non-interactive mode:
codebuddy -p --permission-mode dontAsk "Only allow allowlisted actions, and fail all others directly"
codebuddy -p --permission-mode auto "Try to automatically fix lint errors first"
Additional shortcuts:
-y / --dangerously-skip-permissions: equivalent to --permission-mode bypassPermissions
Persistent Default Value: permissions.defaultMode
Configure in ~/.codebuddy/settings.json or project settings:
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}
Priority order:
1. Current session value
2. CLI --permission-mode
3. permissions.defaultMode
4. default
defaultMode: "auto" has additional limitations:
Only user settings and CLI-injected settings can grant auto
defaultMode: "auto" in .codebuddy/settings.json and .codebuddy/settings.local.json is ignored and falls back to default
If auto is disabled or currently unavailable, it also falls back to default
plan Remembers the Mode Before It Is Entered
When entering plan, CodeBuddy records the permission mode that was active before CodeBuddy enters plan mode. It is restored after CodeBuddy exits. In other words:
When you switch from acceptEdits to plan, regular Read / Bash / non-plan file Edit operations are still processed according to the acceptEdits baseline during plan mode.
Only writes to the current session's plan files are an exception that plan mode additionally allows.
When exiting plan, you return to the previous mode instead of being forced back to default.
Detailed Explanation of Each Mode
default
The most conservative and stable mode.
Tool Type
Action
Read
If the path is within a trusted directory (cwd + permissions.additionalDirectories + user-added addDir), allow it; otherwise, prompt for confirmation.
Edit
Prompt for confirmation
Bash
Prompt for confirmation
Others
Prompt for confirmation
Suitable for:
Entering an unfamiliar repository for the first time
The changes involve sensitive directories, production scripts, and external services.
You want every high-risk action to be visible.
acceptEdits (Auto-Approve File Edits)
Automatically allow Edit tools, but do not allow Bash.
Tool Type
Action
Read
Allow within trusted directories; prompt outside trusted directories.
Edit
Allow automatically
Bash
Prompt for confirmation
Others
Prompt for confirmation
The Edit tools here mainly include:
Edit
Write
MultiEdit
NotebookEdit
Note:
acceptEdits only affects Edit tools and does not affect Bash. Bash always follows a separate security classification.
"Trusted directories" are determined by the workspace root + user-configured permissions.additionalDirectories + the --add-dir option at startup.
Reading from or writing to protected files still prompts for confirmation in the original mode and does not go through automatic approval.
If an operation is first matched by a deny / ask rule, the rule still takes precedence.
Suitable for:
You are willing to let CodeBuddy modify files continuously, but you do not want it to run commands on its own.
You prefer to review changes uniformly through git diff.
auto (Auto-Determined by Classifier)
auto does not mean "fully automatic approval." Instead, it hands over actions that would otherwise trigger an ask to the classifier for a second judgment.
When Does auto Take Over?
The classifier runs only when the following conditions are met:
1. This tool call was not rejected by the deny rule.
2. Nor was it approved in advance by an allow rule.
3. No explicit ask rule was matched.
4. The regular permission chain still ultimately results in an ask.
5. The current mode is auto.
Therefore, auto only takes over the "asks that remain unresolved at the end" and does not replace the entire permission system.
Which Cases Do Not Go to the Classifier?
The following cases do not go through the auto classifier:
Tool calls that have already matched an allow / deny rule
Tool calls that match an explicit ask rule
AskUserQuestion
ExitPlanMode
In other words, ask rules still mean "mandatory manual approval" under auto.
What Results Can the Classifier Return?
The classifier has only two possible outcomes: allow or deny, with no intermediate state such as "partial approval".
What Happens When the Classifier Cannot Determine the Result?
Classifier error / unavailable: For safety, directly deny the action (fail-closed), and prompt the model to use other natural tools to achieve the goal or stop and explain to the user. After consecutive failures, the system automatically exits auto and falls back to default.
The conversation is too long and exceeds the classifier's processing range: Interactive sessions fall back to a standard approval dialog, while headless modes such as -p / stream-json directly terminate the current run.
Too many rejections (repeatedly denied by the classifier in a short period): auto pauses. Interactive sessions fall back to a standard approval dialog, while headless mode terminates the run to avoid repeated idle loops.
These are all automatic behaviors and require no configuration.
auto Mode: Notes on allow Rules
To prevent allow rules from bypassing the classifier entirely, in auto mode CodeBuddy temporarily ignores allow rules that are "too broad / dangerous" (filtered in memory only for the current decision, without modifying your settings). The main rules that are ignored include:
Fully wildcard shell rules: Bash, Bash(*), PowerShell, PowerShell(*)
Dangerous command / cmdlet prefixes: such as Bash(sudo *), Bash(eval *), PowerShell(iex *)
Any Agent / Task rules: such as Agent(*) — prevents bypassing the classifier through sub-agents.
Narrow and specific security rules remain effective, such as Bash(npm test), Bash(git status), PowerShell(Get-Content foo.txt), Read, and Edit(src/foo.ts).
If you truly need certain types of actions to bypass review in auto mode, the correct approach is to configure autoMode rules (see below) instead of writing broad allow rules.
auto Configuration and Self-Test Commands
The trust boundary and allow / deny rules of the auto classifier are controlled by top-level autoMode settings (environment / allow / soft_deny / hard_deny). For details, see Settings.
Three local commands help you view and verify the configuration:
codebuddy auto-mode defaults   # View built-in default rules
codebuddy auto-mode config     # View the currently effective rules (after expanding $defaults)
codebuddy auto-mode critique   # Have the model check whether your custom rules are vague, redundant, or prone to false positives
Suitable for:
You want to reduce routine confirmation pop-ups.
But you do not want to go directly to bypassPermissions.
And you are willing to explicitly configure trust boundaries for internal repos / domains / buckets within your organization.
dontAsk (Reject Unapproved Actions Without Prompting)
The core semantics of dontAsk is: do not prompt for any action that would normally require approval, and deny it directly. It is not an alias for bypassPermissions. On the contrary, it is stricter.
Tool Type
Baseline Behavior
Read
Only read-only operations within trusted directories are allowed to continue; reads outside trusted directories are denied.
Edit
Denied unless pre-approved by an allow rule.
Bash
Denied unless pre-approved by an allow rule.
Others
Denied unless pre-approved by an allow rule.
Important details:
dontAsk only rewrites the final ask result. Actions that are already allow / deny are not affected.
Explicit ask rules do not trigger a prompt under dontAsk. Instead, they are directly converted to deny.
AskUserQuestion and ExitPlanMode are also denied under dontAsk (no prompt is shown / plan approval is not entered). This is because the intent of dontAsk is to "never interrupt the user", so even these interactive tools are no exception.
When denied, the model receives a prompt: it can use other natural tools to achieve the goal, or if the capability is truly necessary, stop and explain to the user.
You can use allowedTools / permissions.allow together with dontAsk to create a "fixed allowlist proxy".
Suitable for:
CI / batch processing / background agents
It explicitly expects to "do it if possible, and fail immediately if not".
A stable and predictable tool surface is required, rather than ad-hoc approval during runtime.
plan (Explore Before Modifying)
The goal of plan mode is to first explore, then draft a plan, and then seek confirmation, rather than immediately applying changes to the source code.
CodeBuddy's plan is not an independent "fully read-only mode". Instead, it is delegated to the mode that was active before plan is entered:
Read: delegate to the previous mode.
Bash: delegate to the previous mode.
Edit: If the target is a plan file of the current session, allow it directly. Otherwise, delegate to the previous mode.
This means that:
When you enter plan from default, regular Edit / Bash operations still trigger a prompt.
When you enter plan from acceptEdits, edits to non-plan files are still automatically allowed according to the acceptEdits baseline.
The only operation that plan truly allows additionally is "writes to the current session's plan files".
How to enter/exit:
Enter: Shift+Tab or EnterPlanMode
Exit: press Shift+Tab again or use ExitPlanMode
Enter plan mode directly at startup:
codebuddy --permission-mode plan
bypassPermissions (Bypass Approvals When Possible)
bypassPermissions skips most normal approval processes and is suitable for isolated containers / VMs / dev containers, sandboxes without public network access, or scripted scenarios where you fully understand the consequences.
However, it does not mean that "all previous rules become invalid". More precisely:
Tools that are not blocked by preceding rules are directly allowed during the bypass phase.
But before that, deny / ask rules are still evaluated first.
In interactive sessions, dangerous Bash commands may still require explicit confirmation.
If permissions.disableBypassPermissionsMode: "disable", this mode falls back to the default baseline.
In other words, the following statements are inaccurate:
Once bypass is enabled, ask rules become invalid.
Once bypass is enabled, dangerous commands are always allowed unconditionally.
Startup method:
codebuddy --permission-mode bypassPermissions
# Equivalent
codebuddy -y
codebuddy --dangerously-skip-permissions
Disabling a Channel (Administrator)
Disable this mode:
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}
Suitable for:
Isolated container / sandbox / dev container
An environment without public network access or shared state
You explicitly accept the consequences of fully automated execution.
delegate (Multi-Agent Coordination Mode)
In delegate mode, the main agent only handles coordination and does not directly execute implementation tools.
Behavior:
The main agent retains only coordination tools, such as Agent, TaskCreate, and SendMessage.
Execution tools, such as Read, Write, Edit, and Bash, are not exposed to the main agent.
The actual read, write, and execution work is delegated to sub-agents.
Suitable for:
The main agent focuses on breaking down tasks, dispatching them, and consolidating results.
You are performing Team/Swarm-style collaborative execution.
work (IDE Integration)
work is only passed in through the IDE-side protocol and is generally not used directly by CLI users.
Tool Type
Action
Read
Allow directly without checking trusted directories.
Edit
Prompt for confirmation
Bash
Allow safe commands directly; prompt for other commands.
Others
Allow
fullAccess (IDE Integration)
It is set only by the IDE client through the protocol and is semantically similar to bypassPermissions.
ignore (For Subagents Only)
ignore is used only for subagent configuration and indicates:
Do not use the mode from the subagent's own frontmatter.
Use the current mode of the parent session.
This value does not appear in the main session.
Protected Critical Files
Write operations to the following paths retain special handling even with acceptEdits / bypassPermissions:
The repository itself: .git, .gitconfig, .gitmodules
shell configuration: .bashrc / .bash_profile / .zshrc / .zprofile / .envrc, and so on
Package management: .npmrc / .yarnrc / .pnpmfile.cjs / bunfig.toml, and so on
IDE / tools: .vscode / .idea / .husky / .devcontainer / .cargo / .yarn / .mvn
CodeBuddy itself: .codebuddy (except .codebuddy/worktrees)
MCP / configuration: .mcp.json / .codebuddy.json
How Subagents Inherit Permission Modes
By default, subagents (Agent tool calls and Agent Teams members) inherit the permission mode of the main session, but the actual precedence is more nuanced than simple inheritance.
To force an override of the default subagent mode at the team / project level:
{
  "permissions": {
    "subagentPermissionMode": "bypassPermissions"
  }
}
Subagent permission mode Priority
When the main session is not auto / dontAsk, the subagent mode is resolved in the following order:
1. The mode explicitly passed in during an Agent tool call
2. The agent's built-in permissionMode in the subagent frontmatter / product config (when set to ignore, the parent session mode is inherited)
3. CLI --subagent-permission-mode
4. Environment variable CODEBUDDY_SUBAGENT_PERMISSION_MODE
5. settings permissions.subagentPermissionMode
6. In-code inheritance mapping
7. Otherwise, the current mode of the main session is inherited directly.
The only special inheritance mapping currently is:
Main session delegate → subagent default changes to default
The reason is simple: the main agent is limited to coordination only, but subagents must be able to actually perform work.
Parent Session Limit for auto / dontAsk
If the main session is currently auto or dontAsk, a permission ceiling is triggered first:
The subagent is directly clamped to the same mode as the parent session.
In this case, even if the Agent tool explicitly passes in a more permissive mode, it will not take effect.
The purpose is to prevent subagents from bypassing the security boundaries of the parent session.
This ceiling also affects the "auto-approval" short-circuit at the interruption layer for background subagents / team members. When the parent session is auto / dontAsk, these short-circuits are disabled, and the normal permission check flow must be followed.
How to Choose for Non-Interactive / Automated Scenarios
If you work in environments where approval dialogs cannot be displayed, such as -p, stream-json, or background agents, it is recommended to understand the modes as follows:
Mode
Typical Result in Non-Interactive Mode
default / acceptEdits / plan
Any action that still requires ask in the end will be rejected.
auto
Actions that would originally trigger an ask are routed to the classifier; when the classifier is unavailable, fail-closed is applied; when the transcript is too long, the run is aborted.
dontAsk
Actions that are not pre-approved are denied directly without waiting for manual confirmation.
bypassPermissions
Most actions proceed directly.
Therefore:
To achieve "fixed allowlist automation" → use dontAsk + allow rules.
To achieve "as much automation as possible while preserving the classifier safety boundary" → use auto.
To achieve "allow almost everything without interruption" → use bypassPermissions.
Using with Permission Rules
A common misconception is treating mode as the sole source of permissions.
In fact, a more recommended understanding is:
mode defines the baseline
allow / ask / deny define exceptions
Example of combining standard rules:
{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Read(/etc/hosts)"],
    "ask": ["WebFetch"],
    "deny": ["Bash(rm -rf *)", "Edit(.git/**)"]
  }
}
Example of fixed allowlist automation:
{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm test:*)"
    ],
    "deny": [
      "Bash(git push:*)"
    ]
  }
}
The effect of the second configuration is:
Read / Grep / Glob are automatically approved.
npm test ... is automatically approved.
git push ... is always denied.
Other unlisted actions are directly denied under dontAsk.
This is exactly the most common practice of granting an agent only a small set of explicit capabilities.
Relevant Resources
Permission Rules: Matching syntax and complete evaluation order for allow / ask / deny
Settings Configuration: Fields such as defaultMode, disableAutoMode, autoMode, and subagentPermissionMode
CLI Reference: Commands such as --permission-mode, --subagent-permission-mode, and codebuddy auto-mode.
Agent Teams: Multi-Agent Collaboration: Collaboration in delegate mode
Sub-agents: Tool and permission mode inheritance for subagents
Hooks System: Extend permission decisions with PreToolUse / PermissionRequest / PermissionDenied.
Non-interactive mode: How to design permission policies in the -p flow
Bash Sandboxing: Add filesystem and network isolation at the command layer.
Security: Overall security model and practical tutorials.
IAM Identity and Access: Organization-level identity authentication and permission control.
﻿

Help and Support

Was this page helpful?

You can also Contact sales or Submit a Ticket for help.

Help us improve! Rate your documentation experience in 5 mins.

Feedback

Mode	Copy	Description
`default`	Not displayed	The default mode does not occupy extra space.
`bypassPermissions`	`⏵⏵ bypass permissions on (shift+tab to cycle)`	Can switch back to other modes cyclically.
`acceptEdits`	`⏵⏵ accept edits on (shift+tab to cycle)`	Can switch back to other modes cyclically.
`auto`	`⏵⏵ auto mode on (shift+tab to cycle)`	Appears only when available.
`dontAsk`	`⏵⏵ don't ask on`	Not in the cycle chain, so there is no cycle hint.
`plan`	`⏸ plan mode on (shift+tab to cycle)`	Indicates that the current mode is plan mode.
`plan` + preceding mode	`⏸ plan + accept edits (shift+tab to cycle)`, and so on	Displays the baseline mode inherited before plan mode.
`delegate`	`⇢ delegate mode on (shift+tab to cycle)`	The main agent only performs coordination.

tencent cloud

Tencent WorkBuddy Enterprise

Permission Mode

Overview

First Understand: Permission Mode Is Just One Layer in the Permission System

Available Modes

Modes That Users Can Switch Manually

Programmatic/Integration Mode (Not in the Shift+Tab Cycle)

How to Switch Permission Modes

Switch During a Session: `Shift+Tab`

Status Bar Indicator

Specify at Startup: `--permission-mode`

Persistent Default Value: `permissions.defaultMode`

`plan` Remembers the Mode Before It Is Entered

Detailed Explanation of Each Mode

default

acceptEdits (Auto-Approve File Edits)

auto (Auto-Determined by Classifier)

When Does auto Take Over?

Which Cases Do Not Go to the Classifier?

What Results Can the Classifier Return?

What Happens When the Classifier Cannot Determine the Result?

`auto` Mode: Notes on allow Rules

`auto` Configuration and Self-Test Commands

dontAsk (Reject Unapproved Actions Without Prompting)

plan (Explore Before Modifying)

bypassPermissions (Bypass Approvals When Possible)

Disabling a Channel (Administrator)

delegate (Multi-Agent Coordination Mode)

work (IDE Integration)

fullAccess (IDE Integration)

ignore (For Subagents Only)

Protected Critical Files

How Subagents Inherit Permission Modes

Subagent permission mode Priority

Parent Session Limit for `auto` / `dontAsk`

How to Choose for Non-Interactive / Automated Scenarios

Using with Permission Rules

Relevant Resources

Help and Support

Mode	What Can Run Without Prompting	Scenario
`default`	Read tools in trusted directories	Default; suitable for sensitive workloads / the onboarding period
`acceptEdits`	Read + Edit tools in trusted directories	Review with `git diff` while making changes.
`auto`	Actions that would originally trigger an ask are handed to the classifier to determine allow / deny.	Reduce interruptions while maintaining security boundaries.
`dontAsk`	Only pre-approved actions continue to run; all others are denied directly without asking.	Non-interactive automation / fixed allowlist agent
`plan`	Delegates to the mode used before plan is entered (default = `default`); additionally allows writing to the session plan file.	Understand the code before making changes and then decide.
`bypassPermissions`	Skip most approvals.	Only for sandbox containers / VMs / offline dev containers
`delegate`	Only coordination tools (such as Agent / TaskCreate / SendMessage / team management) are available; implementation tools are blocked.	The main agent only decomposes and dispatches tasks, delegating execution to subagents.

Mode	When It Occurs
`fullAccess`	The IDE client passes it in through the protocol; semantically, it is close to the global allow-all of `bypassPermissions`.
`work`	Passed in by the IDE client. Read is directly allowed without checking trusted directories, Edit always prompts for confirmation, and for Bash, only safe commands are directly allowed while others prompt for confirmation.
`ignore`	Effective only in subagent / teammate scenarios. It means to use the main session's mode and not be overridden by the subagent's own frontmatter. Not used by the main session.

Tool Type	Action
Read	If the path is within a trusted directory (cwd + `permissions.additionalDirectories` + user-added `addDir`), allow it; otherwise, prompt for confirmation.
Edit	Prompt for confirmation
Bash	Prompt for confirmation
Others	Prompt for confirmation

Tool Type	Baseline Behavior
Read	Only read-only operations within trusted directories are allowed to continue; reads outside trusted directories are denied.
Edit	Denied unless pre-approved by an `allow` rule.
Bash	Denied unless pre-approved by an `allow` rule.
Others	Denied unless pre-approved by an `allow` rule.

Mode	Typical Result in Non-Interactive Mode
`default` / `acceptEdits` / `plan`	Any action that still requires ask in the end will be rejected.
`auto`	Actions that would originally trigger an ask are routed to the classifier; when the classifier is unavailable, fail-closed is applied; when the transcript is too long, the run is aborted.
`dontAsk`	Actions that are not pre-approved are denied directly without waiting for manual confirmation.
`bypassPermissions`	Most actions proceed directly.