Part 2: Hooks, MCP & Security

1. Claude Code Hooks Architecture

Claude Code provides the most comprehensive hook system in the coding agent market, enabling deterministic automation at 8 key lifecycle points. Hooks are external commands or prompts that execute at defined events, giving developers the ability to validate, enrich, block, or redirect agent behavior without modifying the agent itself.

1.1 Hook Event Lifecycle

The lifecycle covers the full span of a coding session, from initialization through prompt processing, tool execution, and termination. Each hook receives a JSON payload via stdin and can influence the agent through structured JSON output on stdout.

All 8 Hook Events

1.2 Hook Configuration

Hooks are configured in .claude/settings.json at the project or user level. Each event contains an array of hook groups, and each group can include a matcher (for tool-specific hooks) and an array of hooks to execute.

// .claude/settings.json
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/setup-env.sh"
      }]
    }],
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/validate-prompt.sh"
      }]
    }],
    "PreToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "node $CLAUDE_PROJECT_DIR/.claude/hooks/check-style.js"
      }]
    },
    {
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/validate-command.sh"
      }]
    }],
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "echo '{\"tool\": \"'$TOOL_NAME'\", \"ts\": \"'$(date -u)'\"}' >> ~/.claude/audit.log"
      }]
    }],
    "Stop": [{
      "hooks": [{
        "type": "prompt",
        "prompt": "Evaluate if all tasks are complete. Check todo list status. If tasks remain, set continue: true."
      }]
    }],
    "PreCompact": [{
      "hooks": [{
        "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/save-critical-context.sh"
      }]
    }],
    "Notification": [{
      "hooks": [{
        "type": "command",
        "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/notify-slack.sh"
      }]
    }]
  }
}

1.3 Hook Decision Control Output

Hooks communicate back to Claude Code via structured JSON on stdout. The schema varies by event type, but the core fields are consistent: hookSpecificOutput for event-specific data, systemMessage for injecting context, and continue for flow control.

// PreToolUse hook response - APPROVE with modification
{
  "hookSpecificOutput": {
    "permissionDecision": "allow",
    "updatedInput": {
      "file_path": "/src/components/Button.tsx",
      "content": "// Auto-formatted by hook\nimport React from 'react';\n..."
    }
  },
  "systemMessage": "Path corrected to match project structure. Content auto-formatted.",
  "continue": true
}

// PreToolUse hook response - DENY with explanation
{
  "hookSpecificOutput": {
    "permissionDecision": "deny",
    "reason": "Cannot write to /etc directory. Use project-local configs instead."
  },
  "systemMessage": "Write blocked by security policy. Suggest alternative path.",
  "continue": true
}

// PostToolUse hook response - BLOCK with feedback
{
  "decision": "block",
  "reason": "ESLint errors detected in output",
  "hookSpecificOutput": {
    "additionalContext": "Fix: Remove unused import on line 5, add missing semicolon on line 12"
  }
}

// UserPromptSubmit hook response - ENRICH with context
{
  "hookSpecificOutput": {
    "additionalContext": "Current sprint: AUTH-2024. Branch: feature/oauth-flow. Test suite: 94% passing."
  },
  "continue": true
}

2. MCP Integration Patterns

The Model Context Protocol (MCP) has become the universal standard for tool integration in AI coding agents. Originally developed by Anthropic, MCP is now governed by the Linux Foundation's Agentic AI Foundation (AAIF), with an ecosystem of 3,000+ servers providing access to external services, APIs, and data sources.

2.1 MCP Architecture

2.2 MCP Server Configuration

MCP servers are configured per-project or globally. The configuration specifies the server command, arguments, and environment variables. Servers are launched as child processes using stdio transport by default.

// ~/.claude.json (global) or .mcp.json (project-level)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/allowed/path"]
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}"
      }
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

// Goose: MCP-first configuration (extensions.yaml)
extensions:
  github:
    type: builtin
    name: github
    env:
      GITHUB_TOKEN: "${GITHUB_TOKEN}"
  jira:
    type: mcp
    command: npx
    args: ["-y", "@anthropic/mcp-server-jira"]
    env:
      JIRA_URL: "${JIRA_URL}"
      JIRA_TOKEN: "${JIRA_TOKEN}"
  custom_api:
    type: mcp
    url: "http://localhost:3001/sse"  # Remote SSE transport

3. MCP Ecosystem

The MCP ecosystem has grown rapidly since its open-source release. With governance now under the Linux Foundation's AAIF, the protocol has achieved broad adoption across all major coding agents and a growing catalogue of community and vendor-maintained servers.

3.1 Popular MCP Servers

3.2 Agent MCP Support Matrix

4. OS-Level Sandboxing

Sandboxing is the most architecturally divergent area across coding agents. Approaches range from OS-kernel enforcement (Codex CLI) to cloud isolation (Warp) to real-time static analysis (Droid) to permission-based workflows (Claude Code, Cline). The right choice depends on the threat model: protecting from accidental damage vs. defending against prompt injection vs. meeting compliance requirements.

4.1 Sandboxing Comparison Matrix

4.2 Codex CLI Sandbox Implementation

Codex CLI implements the most comprehensive OS-native sandboxing, using platform-specific kernel features to restrict file system access and network connectivity at the operating system level.

Seatbelt Profile (macOS)

;; Seatbelt Profile - Scheme-like syntax
;; Applied via sandbox-exec before spawning the agent shell
(version 1)
(deny default)                                    ;; Deny everything by default

;; Allow reading system libraries and tools
(allow file-read* (subpath "/usr"))
(allow file-read* (subpath "/System"))
(allow file-read* (subpath "/Library"))
(allow file-read* (subpath "/private/var/tmp"))

;; Allow read/write only in workspace directory
(allow file-read* file-write* (subpath "/workspace"))

;; Allow process execution (needed for build tools)
(allow process-exec* (subpath "/usr/bin"))
(allow process-exec* (subpath "/workspace/node_modules/.bin"))

;; CRITICAL: Network disabled by default
(deny network*)

;; Allow specific network if --full-auto enables it
;; (deny network-outbound (remote tcp "*:*"))

Landlock + seccomp (Linux)

// Rust implementation from Codex CLI source
pub fn apply_sandbox_policy_to_current_thread(
    policy: &SandboxPolicy,
    cwd: &Path
) -> Result<()> {
    // Step 1: Create Landlock ruleset for filesystem access
    let ruleset = Ruleset::new()
        .handle_access(AccessFs::Execute)?
        .handle_access(AccessFs::WriteFile)?
        .handle_access(AccessFs::ReadFile)?
        .handle_access(AccessFs::ReadDir)?;

    // Step 2: Add read-only paths
    for path in &policy.readable_roots {
        ruleset.add_rule(PathBeneath::new(
            path,
            AccessFs::ReadFile | AccessFs::ReadDir | AccessFs::Execute
        ))?;
    }

    // Step 3: Add writable paths (workspace only)
    for path in &policy.writable_roots {
        ruleset.add_rule(PathBeneath::new(
            path,
            AccessFs::ReadFile | AccessFs::ReadDir |
            AccessFs::WriteFile | AccessFs::Execute
        ))?;
    }

    // Step 4: Block network via seccomp if policy requires
    if !policy.network_access {
        apply_seccomp_network_filter()?;
        // Uses seccomp BPF to block socket(), connect(), bind()
        // syscalls, preventing all network I/O
    }

    // Step 5: Enforce -- irreversible after this point
    ruleset.restrict_self()?;
    Ok(())
}

fn apply_seccomp_network_filter() -> Result<()> {
    // BPF filter blocks: socket(), connect(), bind(), listen(), accept()
    let filter = SeccompFilter::new(vec![
        SeccompRule::new(libc::SYS_socket, SeccompAction::Errno(libc::EPERM)),
        SeccompRule::new(libc::SYS_connect, SeccompAction::Errno(libc::EPERM)),
        SeccompRule::new(libc::SYS_bind, SeccompAction::Errno(libc::EPERM)),
    ])?;
    filter.apply()?;
    Ok(())
}

5. Additional Sandboxing Approaches

Beyond Codex CLI's OS-native approach, several agents have developed novel sandboxing strategies tailored to their deployment models. These range from cloud-native isolation to AI-powered static analysis.

5.1 Warp: Cloud Sandboxes via Namespace

Warp takes a fundamentally different approach by running agent tasks in ephemeral cloud sandboxes provided by Namespace, eliminating the need for local OS sandboxing entirely.

Key Properties

• Short-lived credentials: Each sandbox receives credentials that expire when the task completes. No persistent secrets on disk.
• Sidecar volume architecture: Workspace is mounted read-write; tools and system libraries are read-only sidecars. Prevents system modification.
• Shared cache volumes: Package caches (node_modules, pip, cargo) are shared across sandboxes to avoid redundant downloads, reducing cold-start from minutes to seconds.
• Network isolation: Outbound network is isolated by default; allowlists can be configured per-task.
• SOC 2 compliant: Full audit trail of all sandbox operations for enterprise compliance.

5.2 Droid: DroidShield Real-Time Static Analysis

Factory.ai's Droid takes a unique AI-powered approach to security: rather than sandboxing execution, DroidShield performs real-time static analysis on every code change before it is applied, catching unsafe patterns before they execute.

5.3 Qwen Code: Docker-Based Sandbox

Qwen Code provides an opt-in Docker sandbox activated via the --sandbox CLI flag. This runs the agent's shell commands inside a qwen-code-sandbox container image, providing filesystem and network isolation through standard container boundaries.

# Launch Qwen Code with Docker sandbox
$ qwen-code --sandbox

# Under the hood:
# 1. Pulls/builds qwen-code-sandbox image
# 2. Mounts workspace as /workspace (rw)
# 3. All Bash tool calls execute inside container
# 4. Network access controlled by Docker network policy

# Docker sandbox configuration
docker run --rm \
  -v "$(pwd):/workspace" \
  -w /workspace \
  --network=none \          # Network disabled by default
  --memory=4g \             # Memory limit
  --cpus=2 \                # CPU limit
  qwen-code-sandbox \
  /bin/bash -c "$COMMAND"

5.4 Replit Agent: Cloud Sandbox with Checkpoints

Replit Agent runs entirely in Replit's cloud environment, providing sandbox isolation by default. Its unique contribution is the checkpoint system that captures snapshots of the entire environment state, enabling rollback to any previous point.

6. Approval Workflows

For agents that do not use OS-level sandboxing, the approval workflow is the primary safety mechanism. These range from per-action human approval (Cline) to configurable permission rules (Claude Code) to full bypass ("YOLO") modes for trusted environments.

6.1 Cline's Checkpoint System

Cline implements a shadow git repository that runs alongside the user's actual git repo, creating a checkpoint after every tool call. This enables granular rollback without affecting the user's commit history.

6.2 Auto-Approval Configurations

Cline Auto-Approval Settings

// VS Code settings.json (Cline extension)
{
  "cline.autoApprove": {
    "readOperations": true,       // File reads: auto-approved
    "writeOperations": false,     // File writes: require human approval
    "terminalCommands": false,    // Shell commands: require approval
    "browserActions": false,      // Web automation: require approval
    "mcpTools": false            // MCP server tools: require approval
  },
  "cline.yoloMode": false        // Bypass ALL approvals (dangerous)
}

// YOLO Mode - bypasses all approval checks
// WARNING: Only use in disposable environments (containers, VMs)
{
  "cline.yoloMode": true,
  "cline.yoloModeAllowList": [
    "npm test",
    "npm run build",
    "git status",
    "git diff"
  ]
  // Commands not in allowList still blocked even in YOLO mode
}

Claude Code Permission Levels

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Read(*)",                  // All file reads: auto-approved
      "Bash(git:*)",              // All git commands: auto-approved
      "Bash(npm:test)",           // npm test: auto-approved
      "Bash(npm:run build)",      // npm build: auto-approved
      "Bash(npx:prettier *)",     // Prettier formatting: auto-approved
      "Write(.claude/*)",         // Writing to .claude dir: auto-approved
      "mcp__github__get_*"        // GitHub read operations: auto-approved
    ],
    "deny": [
      "Bash(rm -rf *)",           // Destructive commands: always blocked
      "Write(/etc/*)",            // System files: always blocked
      "Bash(curl *)",             // Network commands: blocked
      "Bash(wget *)",             // Network commands: blocked
      "Bash(sudo *)",             // Privilege escalation: blocked
      "Bash(chmod 777 *)"         // Dangerous permissions: blocked
    ]
  }
}

// Pattern matching supports:
// - Wildcards: * matches any sequence
// - Tool prefixes: Read, Write, Bash, Edit, mcp__*
// - Nested patterns: Bash(git:push origin *)

7. Security Comparison Matrix

The following matrix compares the security posture of all 13 analyzed coding agents across four dimensions: sandbox type, network control, approval model, and compliance certifications.