Hooks¶
This topic describes how to use hooks to run custom code at key points in the agent lifecycle. Hooks let you intercept tool calls, audit agent behavior, enforce policies, inject context, and control execution flow.
How hooks work¶
Hooks follow a four-step process: an event fires, the SDK checks if any matcher applies, it calls your callback, and your callback returns a decision that controls what happens next.
The agent triggers an event (for example, it’s about to call a tool).
The SDK checks each hook matcher registered for that event type.
If a matcher matches (or has no matcher pattern, meaning it matches everything), the SDK calls the associated callback functions.
Each callback returns an output object that can allow, block, or modify the operation.
Hook events¶
The following events are available:
Event |
When it fires |
|---|---|
|
Before a tool executes. Can block the tool or modify its input. |
|
After a tool executes successfully. Can inject additional context. |
|
After a tool execution fails. |
|
When the user sends a prompt. Can inject additional context. |
|
When the agent is about to stop. Can inject context or halt the session. |
|
When a sub-agent starts. |
|
When a sub-agent is about to stop. |
|
Before the conversation is compacted (summarized to fit the context window). |
|
When the agent emits a notification. |
|
When a tool permission check occurs. |
Configuring hooks¶
Pass hooks through the hooks option when creating a session. Each hook event maps to a list of
matchers, and each matcher contains a list of callback functions.
Matchers¶
Each hook matcher has three fields:
Field |
Type |
Description |
|---|---|---|
|
|
A regex pattern used by events that support matching. |
|
list of callbacks |
One or more callback functions to run when the matcher matches. |
|
|
Maximum time in seconds for all callbacks in this matcher. Defaults to 60. |
The matcher field accepts any valid regex pattern. For example:
"Bash"– matches only the Bash tool"Write|Edit"– matches Write or Edit".*"– matches all tools (same as omitting the matcher)
Callback inputs¶
Every callback receives three arguments:
Argument |
Description |
|---|---|
|
An object containing event-specific data. All events include |
|
The tool use ID (for tool-related events) or |
|
A context object. Reserved for future use (for example, abort signals). |
Input fields vary by event:
Event |
Additional input fields |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tool-lifecycle hooks and PermissionRequest can also include optional agent_id and agent_type fields when
they fire from a sub-agent.
Callback outputs¶
Callbacks return an output object that controls execution. The following fields are available:
Field |
Type |
Description |
|---|---|---|
|
|
Whether processing should proceed. Set to |
|
|
Message shown when |
|
|
Set to |
|
|
Feedback message for the agent about the decision. |
|
|
Warning message displayed to the user. |
|
|
Event-specific controls (see below). |
Note
The Python SDK uses continue_ (with a trailing underscore) instead of continue to avoid the Python keyword
conflict. The SDK automatically converts this to continue when communicating with the CLI.
Hook-specific outputs¶
The hookSpecificOutput field accepts event-specific controls:
PreToolUse
Field |
Description |
|---|---|
|
|
|
Reason for the permission decision. |
|
Modified tool input to use instead of the original. |
PostToolUse
Field |
Description |
|---|---|
|
Extra context injected into the conversation after tool execution. |
UserPromptSubmit
Field |
Description |
|---|---|
|
Extra context injected into the conversation. |
PermissionRequest
Field |
Description |
|---|---|
|
|
|
Message shown when denying the permission request. |
Examples¶
Block dangerous tools¶
Prevent the agent from running specific bash commands:
Auto-allow read-only permission requests¶
Allow permission requests for tools that only read data:
Modify tool input¶
Add a timeout to all bash commands before they execute:
Audit logging¶
Log all tool calls for auditing purposes without affecting execution:
Hooks vs. canUseTool¶
Both hooks and the canUseTool callback can intercept tool calls, but they serve different purposes:
Feature |
|
Hooks |
|---|---|---|
Scope |
Pre-execution permission check only |
Multiple lifecycle events (tool lifecycle, prompt submit, stop, sub-agent lifecycle, notification, and compaction) |
Events |
One: permission request |
Ten: |
Pattern matching |
No matcher support. Invoked for permission requests that are not already resolved by rule lists. |
Yes (regex matchers filter by tool name, notification type, or compaction trigger depending on the event) |
Modify input |
Limited. |
Yes ( |
Best for |
Simple allow/deny decisions |
Audit logging, context injection, complex policies, post-execution actions |
You can use both together. The canUseTool callback runs as part of the CLI’s permission system, while
PreToolUse hooks run separately.
Legal notices¶
Where your configuration of Cortex Code uses a model provided on the Model and Service Pass-Through Terms, your use of that model is further subject to the terms for that model on that page.
The data classification of inputs and outputs are as set forth in the following table.
Input data classification |
Output data classification |
Designation |
|---|---|---|
Usage Data |
Customer Data |
Covered AI Features [1] |
For additional information, refer to Snowflake AI and ML.