Summary
Add a tool:before or exec:before hook event that fires before a tool executes, allowing hooks to intercept, modify, or block tool calls.
Use Case
I want to block specific dangerous commands (like gog gmail send, gog gmail delete) while allowing everything else to run freely. Currently:
- The exec-approvals system only supports allowlist mode (no denylist)
- The
tool_result_persist hook fires after execution (too late to block)
- There's no way to intercept commands before they run
Proposed Solution
Add a new hook event:
// Event structure
{
type: 'tool',
action: 'before',
toolName: string, // e.g., 'exec', 'read', 'write'
toolArgs: object, // tool arguments
command?: string, // for exec: the command being run
sessionKey: string,
timestamp: Date,
// Hook can set this to block execution
blocked?: boolean,
blockReason?: string
}
Example Handler
const handler: HookHandler = async (event) => {
if (event.type !== 'tool' || event.action !== 'before') return;
if (event.toolName === 'exec' && event.command?.match(/gog gmail (send|delete)/)) {
event.blocked = true;
event.blockReason = 'Email send/delete requires manual approval';
}
};
Alternatives Considered
- Wrapper scripts - Works but fragile, requires PATH manipulation
- Allowlist mode - Requires maintaining a huge allowlist of "safe" commands
- Agent guardrails - Soft guidance only, not enforced
Environment
Summary
Add a
tool:beforeorexec:beforehook event that fires before a tool executes, allowing hooks to intercept, modify, or block tool calls.Use Case
I want to block specific dangerous commands (like
gog gmail send,gog gmail delete) while allowing everything else to run freely. Currently:tool_result_persisthook fires after execution (too late to block)Proposed Solution
Add a new hook event:
Example Handler
Alternatives Considered
Environment