SDK Permissions

The Claude Agent SDK provides powerful permission controls that allow you to manage how Claude uses tools in your application.

This guide covers how to implement permission systems using the canUseTool callback, hooks, and settings.json permission rules. For complete API documentation, see the TypeScript SDK reference.

Overview

The Claude Agent SDK provides four complementary ways to control tool usage:

1. Permission Modes - Global permission behavior settings that affect all tools
2. canUseTool callback - Runtime permission handler for cases not covered by other rules
3. Hooks - Fine-grained control over every tool execution with custom logic
4. Permission rules (settings.json) - Declarative allow/deny rules with integrated bash command parsing

Use cases for each approach:

• Permission modes - Set overall permission behavior (planning, auto-accepting edits, bypassing checks)
• canUseTool - Dynamic approval for uncovered cases, prompts user for permission
• Hooks - Programmatic control over all tool executions
• Permission rules - Static policies with intelligent bash command parsing

Permission Flow Diagram

Processing Order: PreToolUse Hook → Deny Rules → Allow Rules → Ask Rules → Permission Mode Check → canUseTool Callback → PostToolUse Hook

Permission Modes

Permission modes provide global control over how Claude uses tools. You can set the permission mode when calling query() or change it dynamically during streaming sessions.

Available Modes

The SDK supports four permission modes, each with different behavior:

Setting Permission Mode

You can set the permission mode in two ways:

1. Initial Configuration

Set the mode when creating a query:

import { query } from "@anthropic-ai/claude-agent-sdk";

const result = await query({
  prompt: "Help me refactor this code",
  options: {
    permissionMode: 'default'  // Standard permission mode
  }
});

2. Dynamic Mode Changes (Streaming Only)

Change the mode during a streaming session:

Mode-Specific Behaviors

Accept Edits Mode (acceptEdits)

In accept edits mode:

• All file edits are automatically approved
• Filesystem operations (mkdir, touch, rm, etc.) are auto-approved
• Other tools still require normal permissions
• Speeds up development when you trust Claude's edits
• Useful for rapid prototyping and iterations

Auto-approved operations:

• File edits (Edit, Write tools)
• Bash filesystem commands (mkdir, touch, rm, mv, cp)
• File creation and deletion

Bypass Permissions Mode (bypassPermissions)

In bypass permissions mode:

• ALL tool uses are automatically approved
• No permission prompts appear
• Hooks still execute (can still block operations)
• Use with extreme caution - Claude has full system access
• Recommended only for controlled environments

Mode Priority in Permission Flow

Permission modes are evaluated at a specific point in the permission flow:

1. Hooks execute first - Can allow, deny, ask, or continue
2. Deny rules are checked - Block tools regardless of mode
3. Allow rules are checked - Permit tools if matched
4. Ask rules are checked - Prompt for permission if matched
5. Permission mode is evaluated:
   • bypassPermissions mode - If active, allows all remaining tools
   • Other modes - Defer to canUseTool callback
6. canUseTool callback - Handles remaining cases

This means:

• Hooks can always control tool use, even in bypassPermissions mode
• Explicit deny rules override all permission modes
• Ask rules are evaluated before permission modes
• bypassPermissions mode overrides the canUseTool callback for unmatched tools

Best Practices

1. Use default mode for controlled execution with normal permission checks
2. Use acceptEdits mode when working on isolated files or directories
3. Avoid bypassPermissions in production or on systems with sensitive data
4. Combine modes with hooks for fine-grained control
5. Switch modes dynamically based on task progress and confidence

Example of mode progression:

// Start in default mode for controlled execution
permissionMode: 'default'

// Switch to acceptEdits for rapid iteration
await q.setPermissionMode('acceptEdits')

canUseTool

The canUseTool callback is passed as an option when calling the query function. It receives the tool name and input parameters, and must return a decision- either allow or deny.

canUseTool fires whenever Claude Code would show a permission prompt to a user, e.g. hooks and permission rules do not cover it and it is not in acceptEdits mode.

Here's a complete example showing how to implement interactive tool approval:

Handling the AskUserQuestion Tool

The AskUserQuestion tool allows Claude to ask the user clarifying questions during a conversation. When this tool is called, your canUseTool callback receives the questions and must return the user's answers.

Input Structure

When canUseTool is called with toolName: "AskUserQuestion", the input contains:

{
  questions: [
    {
      question: "Which database should we use?",
      header: "Database",
      options: [
        { label: "PostgreSQL", description: "Relational, ACID compliant" },
        { label: "MongoDB", description: "Document-based, flexible schema" }
      ],
      multiSelect: false
    },
    {
      question: "Which features should we enable?",
      header: "Features",
      options: [
        { label: "Authentication", description: "User login and sessions" },
        { label: "Logging", description: "Request and error logging" },
        { label: "Caching", description: "Redis-based response caching" }
      ],
      multiSelect: true
    }
  ]
}

Returning Answers

Return the answers in updatedInput.answers as a record mapping question text to the selected option label(s):

return {
  behavior: "allow",
  updatedInput: {
    questions: input.questions,  // Pass through original questions
    answers: {
      "Which database should we use?": "PostgreSQL",
      "Which features should we enable?": "Authentication, Caching"
    }
  }
}

Related Resources

• Hooks Guide - Learn how to implement hooks for fine-grained control over tool execution
• Settings: Permission Rules - Configure declarative allow/deny rules with bash command parsing