Automate workflows with hooks

Run shell commands automatically when CSC edits files, finishes tasks, or needs input. Format code, send notifications, validate commands, and enforce project rules.

Hooks are user-defined shell commands that execute at specific points in CSC's lifecycle. They provide deterministic control over CSC's behavior, ensuring certain actions always happen rather than relying on the LLM to choose to run them. Use hooks to enforce project rules, automate repetitive tasks, and integrate CSC with your existing tools.

For decisions that require judgment rather than deterministic rules, you can also use prompt-based hooks or agent-based hooks that use a CSC model to evaluate conditions.

For other ways to extend CSC, see Skills for giving CSC additional instructions and executable commands, Subagents for running tasks in isolated contexts, and Plugins for packaging extensions to share across projects.

Tip: This guide covers common use cases and how to get started. For full event schemas, JSON input/output formats, and advanced features like async hooks and MCP tool hooks, see the Hooks reference.

Set up your first hook

To create a hook, add a hooks block to a settings file. This walkthrough creates a desktop notification hook, so you get alerted whenever CSC is waiting for your input instead of watching the terminal.

Step 1: Add the hook to your settings

Open ~/.costrict/settings.json and add a Notification hook. The example below uses osascript for macOS; see Get notified when CSC needs input for Linux and Windows commands.

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"CSC needs your attention\" with title \"CSC\"'"
          }
        ]
      }
    ]
  }
}

If your settings file already has a hooks key, add Notification as a sibling of the existing event keys rather than replacing the whole object. Each event name is a key inside the single hooks object:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }]
      }
    ],
    "Notification": [
      {
        "matcher": "",
        "hooks": [{ "type": "command", "command": "osascript -e 'display notification \"CSC needs your attention\" with title \"CSC\"'" }]
      }
    ]
  }
}

You can also ask CSC to write the hook for you by describing what you want in the CLI.

Step 2: Verify the configuration

Type /hooks to open the hooks browser. You'll see a list of all available hook events, with a count next to each event that has hooks configured. Select Notification to confirm your new hook appears in the list. Selecting the hook shows its details: the event, matcher, type, source file, and command.

Step 3: Test the hook

Press Esc to return to the CLI. Ask CSC to do something that requires permission, then switch away from the terminal. You should receive a desktop notification.

Tip: The /hooks menu is read-only. To add, modify, or remove hooks, edit your settings JSON directly or ask CSC to make the change.

What you can automate

Hooks let you run code at key points in CSC's lifecycle: format files after edits, block commands before they execute, send notifications when CSC needs input, inject context at session start, and more. For the full list of hook events, see the Hooks reference.

Each example includes a ready-to-use configuration block that you add to a settings file. The most common patterns:

• Get notified when CSC needs input
• Auto-format code after edits
• Block edits to protected files
• Re-inject context after compaction
• Audit configuration changes
• Reload environment when directory or files change
• Auto-approve specific permission prompts

Get notified when CSC needs input

Get a desktop notification whenever CSC finishes working and needs your input, so you can switch to other tasks without checking the terminal.

This hook uses the Notification event, which fires when CSC is waiting for input or permission. Each section below uses the platform's native notification command. Add this to ~/.costrict/settings.json:

macOS

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"CSC needs your attention\" with title \"CSC\"'"
          }
        ]
      }
    ]
  }
}

If no notification appears

osascript routes notifications through the built-in Script Editor app. If Script Editor doesn't have notification permission, the command fails silently, and macOS won't prompt you to grant it. Run this in Terminal once to make Script Editor appear in your notification settings:

osascript -e 'display notification "test"'

Nothing will appear yet. Open System Settings > Notifications, find Script Editor in the list, and turn on Allow Notifications. Run the command again to confirm the test notification appears.

Linux

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "notify-send 'CSC' 'CSC needs your attention'"
          }
        ]
      }
    ]
  }
}

Windows (PowerShell)

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "powershell.exe -Command \"[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('CSC needs your attention', 'CSC')\""
          }
        ]
      }
    ]
  }
}

Auto-format code after edits

Automatically run Prettier on every file CSC edits, so formatting stays consistent without manual intervention.

This hook uses the PostToolUse event with an Edit|Write matcher, so it runs only after file-editing tools. The command extracts the edited file path with jq and passes it to Prettier. Add this to .costrict/settings.json in your project root:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Note: The Bash examples on this page use jq for JSON parsing. Install it with brew install jq (macOS), apt-get install jq (Debian/Ubuntu), or see the jq downloads page.

Block edits to protected files

Prevent CSC from modifying sensitive files like .env, package-lock.json, or anything in .git/. CSC receives feedback explaining why the edit was blocked, so it can adjust its approach.

This example uses a separate script file that the hook calls. The script checks the target file path against a list of protected patterns and exits with code 2 to block the edit.

Step 1: Create the hook script

Save this to .costrict/hooks/protect-files.sh:

#!/bin/bash
# protect-files.sh

INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

PROTECTED_PATTERNS=(".env" "package-lock.json" ".git/")

for pattern in "${PROTECTED_PATTERNS[@]}"; do
  if [[ "$FILE_PATH" == *"$pattern"* ]]; then
    echo "Blocked: $FILE_PATH matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

Step 2: Make the script executable (macOS/Linux)

Hook scripts must be executable for CSC to run them:

chmod +x .costrict/hooks/protect-files.sh

Step 3: Register the hook

Add a PreToolUse hook to .costrict/settings.json that runs the script before any Edit or Write tool call:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.costrict/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

Re-inject context after compaction

When CSC's context window fills up, compaction summarizes the conversation to free space. This can lose important details. Use a SessionStart hook with a compact matcher to re-inject critical context after every compaction.

Any text your command writes to stdout is added to CSC's context. This example reminds CSC of project conventions and recent work. Add this to .costrict/settings.json in your project root:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Reminder: use Bun, not npm. Run bun test before committing. Current sprint: auth refactor.'"
          }
        ]
      }
    ]
  }
}

You can replace the echo with any command that produces dynamic output, like git log --oneline -5 to show recent commits. For injecting context on every session start, consider using AGENTS.md. For environment variables, see CLAUDE_ENV_FILE in the reference.

Audit configuration changes

Track when settings or skills files change during a session. The ConfigChange event fires when an external process or editor modifies a configuration file, so you can log changes for compliance or block unauthorized modifications.

This example appends each change to an audit log. Add this to ~/.costrict/settings.json:

{
  "hooks": {
    "ConfigChange": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{timestamp: now | todate, source: .source, file: .file_path}' >> ~/costrict-config-audit.log"
          }
        ]
      }
    ]
  }
}

The matcher filters by configuration type: user_settings, project_settings, local_settings, policy_settings, or skills. To block a change from taking effect, exit with code 2 or return {"decision": "block"}. See the ConfigChange reference for the full input schema.

Reload environment when directory or files change

Some projects set different environment variables depending on which directory you are in. Tools like direnv do this automatically in your shell, but CSC's Bash tool does not pick up those changes on its own.

A CwdChanged hook fixes this: it runs each time CSC changes directory, so you can reload the correct variables for the new location. The hook writes the updated values to CLAUDE_ENV_FILE, which CSC applies before each Bash command. Add this to ~/.costrict/settings.json:

{
  "hooks": {
    "CwdChanged": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "direnv export bash >> \"$CLAUDE_ENV_FILE\""
          }
        ]
      }
    ]
  }
}

To react to specific files instead of every directory change, use FileChanged with a matcher listing the filenames to watch, separated by |. To build the watch list, this value is split into literal filenames rather than evaluated as a regex. See FileChanged for how the same value also filters which hook groups run when a file changes. This example watches .envrc and .env in the working directory:

{
  "hooks": {
    "FileChanged": [
      {
        "matcher": ".envrc|.env",
        "hooks": [
          {
            "type": "command",
            "command": "direnv export bash >> \"$CLAUDE_ENV_FILE\""
          }
        ]
      }
    ]
  }
}

See the CwdChanged and FileChanged reference entries for input schemas, watchPaths output, and CLAUDE_ENV_FILE details.

Auto-approve specific permission prompts

Skip the approval dialog for tool calls you always allow. This example auto-approves ExitPlanMode, the tool CSC calls when it finishes presenting a plan and asks to proceed, so you aren't prompted every time a plan is ready.

Unlike the exit-code examples above, auto-approval requires your hook to write a JSON decision to stdout. A PermissionRequest hook fires when CSC is about to show a permission dialog, and returning "behavior": "allow" answers it on your behalf.

The matcher scopes the hook to ExitPlanMode only, so no other prompts are affected. Add this to ~/.costrict/settings.json:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "ExitPlanMode",
        "hooks": [
          {
            "type": "command",
            "command": "echo '{\"hookSpecificOutput\": {\"hookEventName\": \"PermissionRequest\", \"decision\": {\"behavior\": \"allow\"}}}'"
          }
        ]
      }
    ]
  }
}

When the hook approves, CSC exits plan mode and restores whatever permission mode was active before you entered plan mode. The transcript shows "Allowed by PermissionRequest hook" where the dialog would have appeared. The hook path always keeps the current conversation: it cannot clear context and start a fresh implementation session the way the dialog can.

To set a specific permission mode instead, your hook's output can include an updatedPermissions array with a setMode entry. The mode value is any permission mode like default, acceptEdits, or bypassPermissions, and destination: "session" applies it for the current session only.

To switch the session to acceptEdits, your hook writes this JSON to stdout:

{
  "hookSpecificOutput": {
    "hookEventName": "PermissionRequest",
    "decision": {
      "behavior": "allow",
      "updatedPermissions": [
        { "type": "setMode", "mode": "acceptEdits", "destination": "session" }
      ]
    }
  }
}

Keep the matcher as narrow as possible. Matching on .* or leaving the matcher empty would auto-approve every permission prompt, including file writes and shell commands. See the PermissionRequest reference for the full set of decision fields.

How hooks work

Hook events fire at specific lifecycle points in CSC. When an event fires, all matching hooks run in parallel, and identical hook commands are automatically deduplicated. The table below shows each event and when it triggers:

Event	When it fires
SessionStart	When a session begins or resumes
UserPromptSubmit	When you submit a prompt, before CSC processes it
PreToolUse	Before a tool call executes. Can block it
PermissionRequest	When a permission dialog appears
PermissionDenied	When a tool call is denied by the auto mode classifier. Return {retry: true} to tell the model it may retry the denied tool call
PostToolUse	After a tool call succeeds
PostToolUseFailure	After a tool call fails
Notification	When CSC sends a notification
SubagentStart	When Subagents are spawned
SubagentStop	When Subagents finish
TaskCreated	When a task is being created via TaskCreate
TaskCompleted	When a task is being marked as completed
Stop	When CSC finishes responding
StopFailure	When the turn ends due to an API error. Output and exit code are ignored
TeammateIdle	When an Agent teams teammate is about to go idle
InstructionsLoaded	When a AGENTS.md or .costrict/rules/*.md file is loaded into context. Fires at session start and when files are lazily loaded during a session
ConfigChange	When a configuration file changes during a session
CwdChanged	When the working directory changes, for example when CSC executes a cd command. Useful for reactive environment management with tools like direnv
FileChanged	When a watched file changes on disk. The matcher field specifies which filenames to watch
WorktreeCreate	When a worktree is being created via --worktree or isolation: "worktree". Replaces default git behavior
WorktreeRemove	When a worktree is being removed, either at session exit or when Subagents finish
PreCompact	Before context compaction
PostCompact	After context compaction completes
Elicitation	When an MCP server requests user input during a tool call
ElicitationResult	After a user responds to an MCP elicitation, before the response is sent back to the server
SessionEnd	When a session terminates

When multiple hooks match, each one returns its own result. For decisions, CSC picks the most restrictive answer. A PreToolUse hook returning deny cancels the tool call no matter what the others return. One hook returning ask forces the permission prompt even if the rest return allow. Text from additionalContext is kept from every hook and passed to CSC together.

Each hook has a type that determines how it runs. Most hooks use "type": "command", which runs a shell command. Three other types are available:

• "type": "http": POST event data to a URL. See HTTP hooks.
• "type": "prompt": single-turn LLM evaluation. See prompt-based hooks.
• "type": "agent": multi-turn verification with tool access. See agent-based hooks.

Read input and return output

Hooks communicate with CSC through stdin, stdout, stderr, and exit codes. When an event fires, CSC passes event-specific data as JSON to your script's stdin. Your script reads that data, does its work, and tells CSC what to do next via the exit code.

Hook input

Every event includes common fields like session_id and cwd, but each event type adds different data. For example, when CSC runs a Bash command, a PreToolUse hook receives something like this on stdin:

{
  "session_id": "abc123",
  "cwd": "/Users/sarah/myproject",
  "hook_event_name": "PreToolUse",
  "tool_name": "Bash",
  "tool_input": {
    "command": "npm test"
  }
}

Your script can parse that JSON and act on any of those fields. UserPromptSubmit hooks get the prompt text, SessionStart hooks get the source (startup, resume, clear, compact), and so on. See common input fields in the reference for shared fields, and each event's section for event-specific schemas.

Hook output

Your script tells CSC what to do next by writing to stdout or stderr and exiting with a specific code. For example, a PreToolUse hook that wants to block a command:

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')

if echo "$COMMAND" | grep -q "drop table"; then
  echo "Blocked: dropping tables is not allowed" >&2
  exit 2
fi

exit 0

The exit code determines what happens next:

• Exit 0: the action proceeds. For UserPromptSubmit and SessionStart hooks, anything you write to stdout is added to CSC's context.
• Exit 2: the action is blocked. Write a reason to stderr, and CSC receives it as feedback so it can adjust.
• Any other exit code: the action proceeds. The transcript shows a <hook name> hook error notice followed by the first line of stderr; the full stderr goes to the debug log.

Structured JSON output

Exit codes give you two options: allow or block. For more control, exit 0 and print a JSON object to stdout instead.

Note: Use exit 2 to block with a stderr message, or exit 0 with JSON for structured control. Don't mix them: CSC ignores JSON when you exit 2.

For example, a PreToolUse hook can deny a tool call and tell CSC why, or escalate it to the user for approval:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Use rg instead of grep for better performance"
  }
}

With "deny", CSC cancels the tool call and feeds permissionDecisionReason back to CSC. These permissionDecision values are specific to PreToolUse:

• "allow": skip the interactive permission prompt. Deny and ask rules, including enterprise managed deny lists, still apply
• "deny": cancel the tool call and send the reason to CSC
• "ask": show the permission prompt to the user as normal

A fourth value, "defer", is available in non-interactive mode with the -p flag. It exits the process with the tool call preserved so an Agent SDK wrapper can collect input and resume. See defer a tool call for later in the reference.

Returning "allow" skips the interactive prompt but does not override permission rules. If a deny rule matches the tool call, the call is blocked even when your hook returns "allow". If an ask rule matches, the user is still prompted. This means deny rules from any settings scope, including managed settings, always take precedence over hook approvals.

Other events use different decision patterns. For example, PostToolUse and Stop hooks use a top-level decision: "block" field, while PermissionRequest uses hookSpecificOutput.decision.behavior. See the summary table in the reference for a full breakdown by event.

For UserPromptSubmit hooks, use additionalContext instead to inject text into CSC's context. Prompt-based hooks (type: "prompt") handle output differently: see prompt-based hooks.

Filter hooks with matchers

Without a matcher, a hook fires on every occurrence of its event. Matchers let you narrow that down. For example, if you want to run a formatter only after file edits (not after every tool call), add a matcher to your PostToolUse hook:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "prettier --write ..." }
        ]
      }
    ]
  }
}

The "Edit|Write" matcher fires only when CSC uses the Edit or Write tool, not when it uses Bash, Read, or any other tool. See matcher patterns for how plain names and regular expressions are evaluated.

Each event type matches on a specific field:

Event	What the matcher filters	Example matcher values
PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, PermissionDenied	tool name	Bash, Edit|Write, mcp__.*
SessionStart	how the session started	startup, resume, clear, compact
SessionEnd	why the session ended	clear, resume, logout, prompt_input_exit, bypass_permissions_disabled, other
Notification	notification type	permission_prompt, idle_prompt, auth_success, elicitation_dialog
SubagentStart	agent type	Bash, Explore, Plan, or custom agent names
PreCompact, PostCompact	what triggered compaction	manual, auto
SubagentStop	agent type	same values as SubagentStart
ConfigChange	configuration source	user_settings, project_settings, local_settings, policy_settings, skills
StopFailure	error type	rate_limit, authentication_failed, billing_error, invalid_request, server_error, max_output_tokens, unknown
InstructionsLoaded	load reason	session_start, nested_traversal, path_glob_match, include, compact
Elicitation	MCP server name	your configured MCP server names
ElicitationResult	MCP server name	same values as Elicitation
FileChanged	literal filenames to watch	.envrc|.env
UserPromptSubmit, Stop, TeammateIdle, TaskCreated, TaskCompleted, WorktreeCreate, WorktreeRemove, CwdChanged	no matcher support	always fires on every occurrence

A few more examples showing matchers on different event types:

Log every Bash command

Match only Bash tool calls and log each command to a file. The PostToolUse event fires after the command completes, so tool_input.command contains what ran. The hook receives the event data as JSON on stdin, and jq -r '.tool_input.command' extracts just the command string, which >> appends to the log file:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' >> ~/.costrict/command-log.txt"
          }
        ]
      }
    ]
  }
}

Match MCP tools

MCP tools use a different naming convention than built-in tools: mcp__<server>__<tool>, where <server> is the MCP server name and <tool> is the tool it provides. For example, mcp__github__search_repositories or mcp__filesystem__read_file. Use a regex matcher to target all tools from a specific server, or match across servers with a pattern like mcp__.*__write.*. See match MCP tools in the reference for the full list of examples.

The command below extracts the tool name from the hook's JSON input with jq and writes it to stderr. Writing to stderr keeps stdout clean for JSON output and sends the message to the debug log:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__github__.*",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"GitHub tool called: $(jq -r '.tool_name')\" >&2"
          }
        ]
      }
    ]
  }
}

Clean up on session end

The SessionEnd event supports matchers on the reason the session ended. This hook only fires on clear (when you run /clear), not on normal exits:

{
  "hooks": {
    "SessionEnd": [
      {
        "matcher": "clear",
        "hooks": [
          {
            "type": "command",
            "command": "rm -f /tmp/claude-scratch-*.txt"
          }
        ]
      }
    ]
  }
}

For full matcher syntax, see the Hooks reference.

Filter by tool name and arguments with the if field

Note: The if field requires CSC v2.1.85 or later. Earlier versions ignore it and run the hook on every matched call.

The if field uses permission rule syntax to filter hooks by tool name and arguments together, so the hook process only spawns when the tool call matches. This goes beyond matcher, which filters at the group level by tool name only.

For example, to run a hook only when CSC uses git commands rather than all Bash commands:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git *)",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.costrict/hooks/check-git-policy.sh"
          }
        ]
      }
    ]
  }
}

The hook process only spawns when the Bash command starts with git. Other Bash commands skip this handler entirely. The if field accepts the same patterns as permission rules: "Bash(git *)", "Edit(*.ts)", and so on. To match multiple tool names, use separate handlers each with its own if value, or match at the matcher level where pipe alternation is supported.

if only works on tool events: PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, and PermissionDenied. Adding it to any other event prevents the hook from running.

Configure hook location

Where you add a hook determines its scope:

Location	Scope	Shareable
~/.costrict/settings.json	All your projects	No, local to your machine
.costrict/settings.json	Single project	Yes, can be committed to the repo
.costrict/settings.local.json	Single project	No, gitignored
Managed policy settings	Organization-wide	Yes, admin-controlled
Plugins hooks/hooks.json	When Plugins is enabled	Yes, bundled with the plugin
Skills or Subagents frontmatter	While the Skills or Subagents is active	Yes, defined in the component file

Run /hooks in CSC to browse all configured hooks grouped by event. To disable all hooks at once, set "disableAllHooks": true in your settings file.

If you edit settings files directly while CSC is running, the file watcher normally picks up hook changes automatically.

Prompt-based hooks

For decisions that require judgment rather than deterministic rules, use type: "prompt" hooks. Instead of running a shell command, CSC sends your prompt and the hook's input data to a CSC model (Haiku by default) to make the decision. You can specify a different model with the model field if you need more capability.

The model's only job is to return a yes/no decision as JSON:

• "ok": true: the action proceeds
• "ok": false: the action is blocked. The model's "reason" is fed back to CSC so it can adjust.

This example uses a Stop hook to ask the model whether all requested tasks are complete. If the model returns "ok": false, CSC keeps working and uses the reason as its next instruction:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check if all tasks are complete. If not, respond with {\"ok\": false, \"reason\": \"what remains to be done\"}."
          }
        ]
      }
    ]
  }
}

For full configuration options, see prompt-based hooks in the reference.

Agent-based hooks

When verification requires inspecting files or running commands, use type: "agent" hooks. Unlike prompt hooks which make a single LLM call, agent hooks spawn a Subagent that can read files, search code, and use other tools to verify conditions before returning a decision.

Agent hooks use the same "ok" / "reason" response format as prompt hooks, but with a longer default timeout of 60 seconds and up to 50 tool-use turns.

This example verifies that tests pass before allowing CSC to stop:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "agent",
            "prompt": "Verify that all unit tests pass. Run the test suite and check the results. $ARGUMENTS",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

Use prompt hooks when the hook input data alone is enough to make a decision. Use agent hooks when you need to verify something against the actual state of the codebase.

For full configuration options, see agent-based hooks in the reference.

HTTP hooks

Use type: "http" hooks to POST event data to an HTTP endpoint instead of running a shell command. The endpoint receives the same JSON that a command hook would receive on stdin, and returns results through the HTTP response body using the same JSON format.

HTTP hooks are useful when you want a web server, cloud function, or external service to handle hook logic: for example, a shared audit service that logs tool use events across a team.

This example posts every tool use to a local logging service:

{
  "hooks": {
    "PostToolUse": [
      {
        "hooks": [
          {
            "type": "http",
            "url": "http://localhost:8080/hooks/tool-use",
            "headers": {
              "Authorization": "Bearer $MY_TOKEN"
            },
            "allowedEnvVars": ["MY_TOKEN"]
          }
        ]
      }
    ]
  }
}

The endpoint should return a JSON response body using the same output format as command hooks. To block a tool call, return a 2xx response with the appropriate hookSpecificOutput fields. HTTP status codes alone cannot block actions.

Header values support environment variable interpolation using $VAR_NAME or ${VAR_NAME} syntax. Only variables listed in the allowedEnvVars array are resolved; all other $VAR references remain empty.

For full configuration options and response handling, see HTTP hooks in the reference.

Limitations and troubleshooting

Limitations

• Command hooks communicate through stdout, stderr, and exit codes only. They cannot trigger / commands or tool calls. Text returned via additionalContext is injected as a system reminder that CSC reads as plain text. HTTP hooks communicate through the response body instead.
• Hook timeout is 10 minutes by default, configurable per hook with the timeout field (in seconds).
• PostToolUse hooks cannot undo actions since the tool has already executed.
• PermissionRequest hooks do not fire in non-interactive mode (-p). Use PreToolUse hooks for automated permission decisions.
• Stop hooks fire whenever CSC finishes responding, not only at task completion. They do not fire on user interrupts. API errors fire StopFailure instead.
• When multiple PreToolUse hooks return updatedInput to rewrite a tool's arguments, the last one to finish wins. Since hooks run in parallel, the order is non-deterministic. Avoid having more than one hook modify the same tool's input.

Hooks and permission modes

PreToolUse hooks fire before any permission-mode check. A hook that returns permissionDecision: "deny" blocks the tool even in bypassPermissions mode or with --dangerously-skip-permissions. This lets you enforce policy that users cannot bypass by changing their permission mode.

The reverse is not true: a hook returning "allow" does not bypass deny rules from settings. Hooks can tighten restrictions but not loosen them past what permission rules allow.

Hook not firing

The hook is configured but never executes.

• Run /hooks and confirm the hook appears under the correct event
• Check that the matcher pattern matches the tool name exactly (matchers are case-sensitive)
• Verify you're triggering the right event type (e.g., PreToolUse fires before tool execution, PostToolUse fires after)
• If using PermissionRequest hooks in non-interactive mode (-p), switch to PreToolUse instead

Hook error in output

You see a message like "PreToolUse hook error: ..." in the transcript.

• Your script exited with a non-zero code unexpectedly. Test it manually by piping sample JSON:

  echo '{"tool_name":"Bash","tool_input":{"command":"ls"}}' | ./my-hook.sh
  echo $?  # Check the exit code

• If you see "command not found", use absolute paths or $CLAUDE_PROJECT_DIR to reference scripts
• If you see "jq: command not found", install jq or use Python/Node.js for JSON parsing
• If the script isn't running at all, make it executable: chmod +x ./my-hook.sh

/hooks shows no hooks configured

You edited a settings file but the hooks don't appear in the menu.

• File edits are normally picked up automatically. If they haven't appeared after a few seconds, the file watcher may have missed the change: restart your session to force a reload.
• Verify your JSON is valid (trailing commas and comments are not allowed)
• Confirm the settings file is in the correct location: .costrict/settings.json for project hooks, ~/.costrict/settings.json for global hooks

Stop hook runs forever

CSC keeps working in an infinite loop instead of stopping.

Your Stop hook script needs to check whether it already triggered a continuation. Parse the stop_hook_active field from the JSON input and exit early if it's true:

#!/bin/bash
INPUT=$(cat)
if [ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0  # Allow CSC to stop
fi
# ... rest of your hook logic

JSON validation failed

CSC shows a JSON parsing error even though your hook script outputs valid JSON.

When CSC runs a hook, it spawns a shell that sources your profile (~/.zshrc or ~/.bashrc). If your profile contains unconditional echo statements, that output gets prepended to your hook's JSON:

Shell ready on arm64
{"decision": "block", "reason": "Not allowed"}

CSC tries to parse this as JSON and fails. To fix this, wrap echo statements in your shell profile so they only run in interactive shells:

# In ~/.zshrc or ~/.bashrc
if [[ $- == *i* ]]; then
  echo "Shell ready"
fi

The $- variable contains shell flags, and i means interactive. Hooks run in non-interactive shells, so the echo is skipped.

Debug techniques

The transcript view, toggled with Ctrl+O, shows a one-line summary for each hook that fired: success is silent, blocking errors show stderr, and non-blocking errors show a <hook name> hook error notice followed by the first line of stderr.

For full execution details including which hooks matched, their exit codes, stdout, and stderr, read the debug log. Start CSC with csc --debug-file /tmp/claude.log to write to a known path, then tail -f /tmp/claude.log in another terminal. If you started without that flag, run /debug mid-session to enable logging and find the log path.