Permissions

Configure Permissions

Control what Hawa Code can access and execute through fine-grained permission rules, patterns, and management strategies.

Hawa Code supports fine-grained permissions, allowing you to precisely specify what actions agents are allowed and prohibited from performing. Permission settings can be version-controlled and distributed to all developers in an organization, while also being customizable by individual developers.

Permission System

Hawa Code uses a layered permission system to balance functionality and security:

Tool Type	Examples	Requires Approval	“Yes, don’t ask again” Effect
Read-only	File reading, Grep	No	Not applicable
Bash commands	Shell execution	Yes	Permanent per project directory and command, persisted to project’s settings configuration file
File modifications	Edit/Write files	Yes	Valid until session ends, stored in memory, expires after Hawa Code restart

Managing Permissions

The settings.json file can be used to configure related permissions.

• Allow: Allows Hawa Code to use specified tools without manual approval.
• Deny: Prevents Hawa Code from using specified tools.

Rules are evaluated in order: Deny -> Allow. The first matching rule takes effect, so deny rules always take precedence.

Permission Modes

Hawa Code supports multiple permission modes to control how tool approvals work. Refer to permission modes for when to use each mode. Set defaultMode in the settings file:

Mode	Description
default	Standard behavior: prompts for permissions on first use of each tool
acceptEdits	Automatically accepts file editing permissions for the session
plan	Plan mode: Hawa can analyze but cannot modify files or execute commands
auto	Automatically approves tool calls with background safety checks to verify operations match your request. Currently in research preview
dontAsk	Automatically rejects tools unless pre-approved via /permissions or permissions.allow rules
bypassPermissions	Skips permission prompts unless writing to protected directories (see warning below)

bypassPermissions mode skips permission prompts. Writing to .git, .hcode, .vscode, and .idea directories will still prompt for confirmation to prevent accidental damage to repository state and local configuration. Writing to .hcode/commands, .hcode/agents, and .hcode/skills directories is unrestricted and will not prompt, as Hawa Code frequently writes to these directories when creating skills, subagents, and commands. Only use this mode in isolated environments (such as containers or virtual machines) to avoid damage from Hawa Code. Administrators can disable this mode by setting disableBypassPermissionsMode to “disable” in managed settings.

Permission Rule Syntax

Permission rules follow the format Tool or Tool(qualifier).

Matching All Uses of a Tool

To match all uses of a tool, simply use the tool name without parentheses:

Rule	Effect
Bash	Matches all Bash commands
WebFetch	Matches all web fetch requests
Read	Matches all file reads

Bash(*) is equivalent to Bash, matching all Bash commands.

Fine-grained Control with Qualifiers

Add qualifiers in parentheses to match specific tool uses:

Rule	Effect
Bash(npm run build)	Matches the exact command npm run build
Read(./.env)	Matches reading the .env file in the current directory
WebFetch(domain:example.com)	Matches fetch requests to example.com

Wildcard Patterns

Bash rules support glob patterns using *. Wildcards can appear anywhere in the command. The following configuration allows npm and git commit commands while blocking git push:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

The space before * is important: Bash(ls *) matches ls -la but not lsof, while Bash(ls*) matches both.

Tool-specific Permission Rules

Bash

Bash permission rules support wildcard matching using *. Wildcards can appear anywhere in the command, including at the beginning, middle, or end:

• Bash(npm run build) matches the exact Bash command npm run build
• Bash(npm run test *) matches Bash commands starting with npm run test
• Bash(npm *) matches any command starting with npm
• Bash(* install) matches any command ending with install
• Bash(git * main) matches commands like git checkout main, git merge main

When * appears at the end with a space before it (like Bash(ls *)), it enforces word boundaries, requiring the prefix to be followed by a space or end of string. For example, Bash(ls *) matches ls -la but not lsof. In contrast, Bash(ls*) without a space matches both ls -la and lsof because there is no word boundary restriction.

Hawa Code recognizes shell operators (like &&), so prefix matching rules like Bash(safe-cmd *) do not grant permission to run safe-cmd && other-cmd commands.

When you approve compound commands with “Yes, don’t ask again”, Hawa Code saves separate rules for each subcommand that requires approval, rather than saving a single rule for the entire compound string. For example, approving git status && npm test saves a rule for npm test, so future npm test calls will be recognized regardless of what precedes the &&. Subcommands like cd into subdirectories generate their own Read rules for that path. Up to 5 rules can be saved for a single compound command.

Read and Edit

Edit rules apply to all built-in tools that edit files. Hawa Code attempts to apply Read rules to all built-in tools that read files, such as Grep and Glob.

Read and Edit deny rules apply to Hawa Code’s built-in file tools, not to Bash subprocesses. A Read(./.env) deny rule blocks the Read tool but does not block cat .env in Bash. To enable OS-level enforcement that blocks all processes from accessing a path, enable sandboxing.

Pattern	Meaning	Example	Matches
/path	Absolute path from filesystem root	Read(/Users/alice/secrets/**)	/Users/alice/secrets/**
~/path	Path starting from home directory	Read(~/Documents/*.pdf)	/Users/alice/Documents/*.pdf
path or ./path	Path relative to project root	Edit(/src/**/*.ts)	/src/**/*.ts

MCP

• mcp__test matches any tool provided by the test server (name configured in Hawa Code)
• mcp__test__* wildcard syntax that also matches all tools from the test server
• mcp__test__call matches the call tool provided by the test server

WebFetch

WebFetch(domain:test.com) matches fetch requests to test.com

Agent (subagents)

Use Agent(AgentName) rules to control which subagents Hawa Code can use:

• Agent(Explore) matches the Explore subagent
• Agent(Plan) matches the Plan subagent
• Agent(my-custom-agent) matches a custom subagent named my-custom-agent