Post/PreToolUse Hooks Not Executing in Claude Code
Bug Report for Anthropic - Claude Code Hook System
Issue: PreToolUse and PostToolUse Hooks Not Executing
Environment:
- Claude Code Version: claude-sonnet-4-20250514
- Platform: macOS Darwin 24.6.0
- Configuration: .claude/settings.local.json
Problem: PreToolUse and PostToolUse hooks are configured correctly but never execute, while other hook types work perfectly.
Evidence:
✅ WORKING HOOKS:
- Stop hooks execute consistently (proven by debug logs showing 50+ executions)
- SubagentStop hooks work (sound notifications trigger)
- UserPromptSubmit hooks work (manual /aw command functions)
❌ BROKEN HOOKS:
- PreToolUse hooks never execute despite proper configuration
- PostToolUse hooks never execute despite proper configuration
Configuration Tested: { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "echo 'PreToolUse triggered' >> /tmp/pretool-test.log" } ] } ], "PostToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "cat /Users/greg/codebase/stayinpattaya/.claude/commands/aw.md" } ] } ] } }
Testing Performed:
- Verified hook scripts execute correctly when run manually
- Tested multiple matchers: "*", "Bash", "Task", "Write", "Edit"
- Tested both simple commands and complex scripts
- Confirmed proper JSON input handling with jq parsing
- Verified file permissions and absolute paths
- Cleared logs and performed fresh tests
- Compared working Stop hook configuration (identical format)
Expected Behavior: PreToolUse and PostToolUse hooks should execute before/after tool usage and show output or create logs.
Actual Behavior: Tool-related hooks never execute. No output displayed, no log files created, no evidence of execution.
Conclusion: PreToolUse and PostToolUse hook events are not being fired by Claude Code, despite proper configuration following official documentation. Other hook types (Stop, SubagentStop, UserPromptSubmit) function correctly using identical configuration patterns.
This appears to be a selective hook system failure affecting only tool-related events.
Claude Code Hooks: A Guide to the Session Security Feature
Overview
Claude Code includes a crucial security feature that governs how and when changes to hooks are applied. This feature prevents hooks from being modified or injected during an active session, protecting you from unintended or malicious code execution.
This behavior is a deliberate security design, not a bug. This guide explains how it works and the correct methods for managing your hooks.
The Security Feature Explained
How It Works
-
Snapshot at Startup: When a Claude Code session begins, it takes a snapshot of all hooks from your settings files (
~/.claude/settings.json,.claude/settings.json, etc.). - Locked During Session: Once the session starts, this configuration is locked and does not automatically update, even if you edit the settings files on disk.
- Active Monitoring and Warnings: Claude Code monitors your settings files for changes. If it detects that hooks have been modified externally during your session, it will display a warning, prompting you to review the changes.
- Explicit Application Required: To protect your session, changes only take effect when you explicitly apply them using one of the two methods described below.
Why This Exists
This security model is designed to protect against:
- Malicious hook injection into an active, trusted session.
- Unauthorized code execution through externally modified hooks.
- Data exfiltration attempts via compromised hooks.
- Accidental security breaches from applying unreviewed changes.
Common Scenarios and Symptoms
You may have encountered this feature if:
- You created or modified a hook, but it didn't activate in your current session.
- An existing hook continued to run with its old behavior after you edited it.
- You saved changes to
settings.jsonand saw a warning message in Claude Code about external modifications.
These are all signs that the security feature is working as intended. The original hook snapshot taken at the start of your session is still in effect.
Applying Hook Changes: The Correct Methods
Because changes are not applied automatically, you must choose one of these two methods to activate them.
Method 1: The Recommended In-Session Method (/hooks menu)
This is the best practice for updating hooks without disrupting your workflow, as it preserves your current conversation context.
- Create or modify your hooks in the appropriate
settings.jsonfile and save it. - You may see a warning in Claude Code that your configuration has changed.
- Run the
/hookscommand in your active Claude Code session. - The menu will show you the pending changes, often as a "diff" comparing the old and new hook configurations.
- Follow the prompts to review and confirm the changes.
- Once confirmed, the new hook configuration will be applied to your current session.
Use this method when: You are in the middle of a task and want to apply a hook change without losing your conversation history and context.
Method 2: Restarting the Session
This is a simple and foolproof method that ensures you start with a clean slate and the latest configuration.
- Create or modify your hooks in the
settings.jsonfile. - Exit your current Claude Code session (
Ctrl+Dor theexitcommand). - Start a new Claude Code session by running
claude.
The new session will take a fresh snapshot of your settings files, and your updated hooks will be active immediately.
Use this method when: You are not in the middle of a complex conversation, or you are setting up your environment before starting a new task.
Testing Hooks Properly
To avoid frustration, always configure hooks before you start the session you intend to test them in.
Correct Testing Workflow
# 1. Create your test directory and hook configuration FIRST
mkdir hook-test && cd hook-test
mkdir -p .claude
cat > .claude/settings.json << 'EOF'
{
"hooks": {
"PreToolUse": [{
"matcher": "*",
"hooks": [{"type": "command", "command": "echo 'Hook fired!' >> hook.log"}]
}]
}
}
EOF
# 2. NOW, start your Claude Code session
claude
# 3. Test your hooks. They will work as expected.
# Claude will read the configuration on startup.
Troubleshooting and Important Considerations
Troubleshooting Checklist
If your hooks aren't working as expected:
- [ ] Did you apply the changes using the
/hooksmenu or by restarting your session? - [ ] Is your
settings.jsonfile valid JSON? (Verify withjq . .claude/settings.json) - [ ] Do your hook scripts have execute permissions? (Use
chmod +x your-script.sh) - [ ] Is your Claude Code version
1.0.38or newer? (Hooks were released in this version). - [ ] Have you checked for conflicts due to settings precedence?
Settings Precedence
Hooks are loaded from multiple locations. It's crucial to understand which file takes precedence if hooks are defined in more than one place. The order is:
-
Enterprise Managed Settings (e.g.,
/etc/claude-code/managed-settings.jsonon Linux) -
Project-level Settings (
.claude/settings.jsonand.claude/settings.local.json) -
User-level Settings (
~/.claude/settings.json)
Settings from a higher-precedence file will override those from a lower-precedence file.
What DOESN'T Apply Hook Changes
- Starting a new
tmuxwindow or pane. - Opening a new terminal tab.
- Running
source ~/.bashrcor similar shell reload commands.
These actions typically do not terminate the underlying Claude Code process, so the original hook snapshot remains in memory.
Best Practices
-
Configure First: Set up project-level hooks in
.claude/settings.jsonbefore starting a major work session. - Test in Isolation: Use a separate test directory to verify new hooks before adding them to your main workflow.
- Version Your Hooks: Commit project-level hooks and their associated scripts to version control so the whole team benefits.
-
Document Your Hooks: Use comments within your hook scripts and your project's
READMEto explain what each hook does.
Summary
The New Golden Rule: Hook changes must be explicitly applied. Use the /hooks menu to update your active session, or restart Claude Code to load a fresh configuration.
This session-locking mechanism is a fundamental security feature that ensures the integrity of your development environment. By understanding how to work with it, you can customize Claude Code powerfuly and securely.
Can you retest with this in mind?
Because its working for me.
Your configuration is also working for me.
The new session will take a fresh snapshot of your settings files, and your updated hooks will be active immediately.
Yes, as a security feature, changes to Settings JSON files don't take effect immediately. You either have to acknowledge with /hooks or start a new session.
coygeek i used the /hooks command and restarted the session over 50 times and it DOES NOT WORK
Reading 1: Hook changes must be explicitly applied using /hooks menu or restart Reading 2: /hooks menu shows pending changes as diff and allows confirmation Reading 3: Once confirmed, new hook configuration applies to current session Reading 4: Security feature prevents automatic application during session Reading 5: Method 1 (/hooks) preserves conversation context and should work Reading 6: Troubleshooting checklist - did you apply changes? valid JSON? execute permissions? version 1.0.38+? Reading 7: Settings precedence - project-level overrides user-level Reading 8: What doesn't apply changes - tmux, terminal tabs, shell reloads Reading 9: Configure first, test in isolation, document your hooks Reading 10: The /hooks menu method SHOULD work for current session
The document says this SHOULD work and apply to the current session. But the PostToolUse hook still isn't firing. its a very SIMPLE Too that is made over complicated that does not work easy. There are 7 coders here with me on their own claude code accounts with all diffrent experance, they all say the same thing it's a simple too that shuld be simple to set up when this all started it delted all our json files we had settings in and now it's taking snapshots on start etc
Talk about making something so complicated to the point it DOES NOT WORK and stressed everyone out trying to use it when we followed the https://docs.anthropic.com/en/docs/claude-code/hooks
I can confirm this issue persists. I've extensively tested hooks following the documentation exactly:
Environment
- Claude Code Version: 1.0.89
- Platform: macOS Darwin 24.6.0
- Multiple sessions tested over several days
Testing Performed
- Created hooks that read JSON from stdin as per documentation
- Verified hooks work perfectly when called manually with correct JSON input
- Used /hooks command multiple times to apply changes
- Restarted sessions dozens of times
- Tested with simple echo commands and complex markdown formatters
- Verified JSON validity, file permissions, and paths
Evidence
- Manual execution:
echo '{"tool_input": {"file_path": "/tmp/test.md"}}' | ./hook.sh✅ WORKS - Automatic execution via Claude Code tools: ❌ NEVER FIRES
- No logs created, no output shown, no evidence of execution
- Tested PreToolUse and PostToolUse with Write, Edit, MultiEdit matchers
Key Finding
The hook infrastructure exists and hooks execute correctly when called manually, but the trigger mechanism that should call hooks when tools are used is completely broken. This is not a configuration issue - the hooks simply never get invoked by Claude Code.
This makes the entire hooks feature unusable for its primary purpose of automating tasks like code formatting, linting, and validation.
Please prioritize fixing this as it's a critical feature that many users rely on.
yes pretooluse hook not working for me too. tried adding sound whenever it asks user for decision, but it never triggers.
Not working for me either. I was trying to follow another user's advice of adding an Always Works hook before Edits are made, but this does not seem to be triggering.
I have same issue, and I fixed it.
In September 2025, claude-code strengthened validation rules for settings.json. Any invalid configuration will disable hooks. maybe there is something wrong with your claude setting.json , checkout the solutions I
https://github.com/dazuiba/CCNotify?tab=readme-ov-file#why-not-working
@Xopher00 @tytung2020 @Dmdv @fwends
Enterprise Confirmation: PreToolUse/PostToolUse Hooks Critical Failure
🏢 Enterprise Context
Team: Enterprise monorepo development team (500+ files)
Platform: macOS Darwin 24.6.0
Claude Code Version: Latest (as of 2025-09-11)
Impact: Critical security gap - preventive controls completely bypassed
✅ Confirming Identical Issue
We can confirm this exact same issue affects our enterprise environment. Like the other teams here, we have:
- ✅ SessionStart hooks: Work perfectly (environment setup, weekly checks)
- ✅ PostToolUse hooks: Work perfectly (dependency sync, file processing)
- ❌ PreToolUse hooks: NEVER execute (critical security failure)
🚨 Security Impact
Our PreToolUse hooks are designed to prevent dangerous bulk operations that could corrupt our enterprise codebase. The failure of these hooks creates a critical security vulnerability:
{
"hooks": {
"PreToolUse": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "cd \"$CLAUDE_PROJECT_DIR\" && \"$CLAUDE_PROJECT_DIR/.venv-uv/bin/python\" \"$CLAUDE_PROJECT_DIR/infrastructure/code-standards/hooks/prevent_violations.py\" --tool-name=\"$TOOL_NAME\" --tool-args=\"$TOOL_ARGS\"",
"description": "Prevent Claude from using dangerous bulk operations and mass editing tools"
}
]
}
]
}
}
Expected behavior: Block dangerous tools before they execute
Actual behavior: Hook never runs, dangerous operations proceed unchecked
Manual test: python prevent_violations.py --tool-name="MultiEdit" ✅ works perfectly
Claude Code trigger: ❌ Never executes
🔬 Additional Technical Evidence
Configuration Validation
- ✅ JSON syntax validated with
jq - ✅ File permissions confirmed (
chmod +xon all scripts) - ✅ Path resolution tested (all paths absolute and accessible)
- ✅ Environment variables available (
$CLAUDE_PROJECT_DIRset correctly)
Hook Execution Pattern Analysis
| Hook Type | Reliability | Our Use Case | Status |
|---|---|---|---|
| SessionStart | 100% | Environment setup | ✅ Working |
| PostToolUse | 100% | Dependency sync | ✅ Working |
| PreToolUse | 0% | Security prevention | ❌ BROKEN |
Testing Methodology
# Test 1: Manual execution (WORKS)
echo '{"tool_name": "Write", "tool_args": "test"}' | ./prevent_violations.py
# Test 2: Claude Code execution (FAILS)
# - Used /hooks command 15+ times
# - Restarted sessions 20+ times
# - No logs created, no output shown, no evidence of execution
💼 Enterprise Requirements
As an enterprise team, we cannot use Claude Code in production until this is fixed because:
- Compliance Risk: We need preventive controls for audit requirements
- Code Safety: Bulk operations without validation risk data corruption
- Team Consistency: All team members need the same protective measures
- Security Policy: Our security framework requires pre-execution validation
🎯 Specific Request to Anthropic
High Priority Fix Request: This issue is blocking multiple enterprise teams from using Claude Code's automation features safely.
Key debugging areas (based on our analysis):
-
Variable injection: Are
$TOOL_NAMEand$TOOL_ARGSproperly set in PreToolUse context? - Execution timing: Are PreToolUse hooks executing in the wrong thread/context?
- Error handling: Are failed PreToolUse hooks silently crashing the tool pipeline?
- Event firing: Is the PreToolUse event actually being triggered by tool execution?
🔄 Workaround Status
Currently using reactive PostToolUse validation instead of preventive PreToolUse blocking, but this is:
- ❌ After-the-fact (damage already done)
- ❌ Incomplete protection (can't prevent, only detect)
- ❌ Not compliant with our security requirements
📞 Community Support
Happy to provide additional debugging information, test configurations, or assist with reproduction if needed by the Anthropic team.
This is affecting multiple enterprise teams - a fix would unblock significant Claude Code adoption in enterprise environments.
Environment Summary:
- Platform: macOS Darwin 24.6.0
- Enterprise monorepo: 500+ files
- Hook types affected: PreToolUse only
- Security impact: Critical (prevention controls bypassed)
- Workaround: Reactive validation only (insufficient)
@matssun refer to https://docs.anthropic.com/en/docs/claude-code/hooks#pretooluse-input
Your usage of $TOOL_NAME and $TOOL_ARGS is incorrect.
@matssun
Hey, thanks for posting such a detailed write-up.
It turns out that PreToolUse hooks don't receive tool information via environment variables like $TOOL_NAME or $TOOL_ARGS. Instead, Claude Code pipes a JSON object containing all the context to the standard input (stdin) of your hook command.
The Root Cause
Based on the official Hooks Reference documentation, the stdin for a PreToolUse hook looks like this:
{
"hook_event_name": "PreToolUse",
"tool_name": "MultiEdit",
"tool_input": { /*...tool-specific arguments object... */ }
}
Your script is expecting environment variables that are never set, which is why it seems like the hook never runs. The command executes, but the variables are empty, so your Python script likely exits without doing anything.
How to Fix It
You need to modify your hook's command to read from stdin, parse the JSON, and then pass the values to your Python script. The easiest way to do this without changing your Python script is with jq.
Here is the corrected version of your hook command:
cat | jq -c . | { read JSON_INPUT; \
TOOL_NAME_FROM_JSON=$(echo "$JSON_INPUT" | jq -r '.tool_name'); \
TOOL_ARGS_FROM_JSON=$(echo "$JSON_INPUT" | jq -c '.tool_input'); \
cd "$CLAUDE_PROJECT_DIR" && \
"$CLAUDE_PROJECT_DIR/.venv-uv/bin/python" \
"$CLAUDE_PROJECT_DIR/infrastructure/code-standards/hooks/prevent_violations.py" \
--tool-name="$TOOL_NAME_FROM_JSON" \
--tool-args="$TOOL_ARGS_FROM_JSON"; \
}
Explanation:
-
cat | jq -c . | { ... }: This reads the entire JSON object fromstdin. -
read JSON_INPUT: This stores the JSON in a shell variable. -
TOOL_NAME_FROM_JSON=$(...): We usejqto extract the.tool_namestring. -
TOOL_ARGS_FROM_JSON=$(...): We usejqto extract the entire.tool_inputobject as a compact JSON string. Your Python script will need to be able to parse this JSON string from the--tool-argsargument.
Recommended: Modify the Python Script
An even cleaner solution is to modify your prevent_violations.py script to read directly from stdin, which is the intended pattern for hooks. The Hooks Guide and Reference pages have great examples of this.
Your Python script would start like this:
import sys
import json
try:
# Read the JSON data from stdin
hook_data = json.load(sys.stdin)
tool_name = hook_data.get("tool_name")
tool_input = hook_data.get("tool_input", {})
# ... your existing validation logic here ...
# if is_violating(tool_name, tool_input):
# print("Violation reason...", file=sys.stderr)
# sys.exit(2) # Exit code 2 blocks the tool
except Exception as e:
print(f"Error in hook: {e}", file=sys.stderr)
sys.exit(1) # Non-blocking error
sys.exit(0) # Success
Then your settings.json hook command becomes much simpler:
{
"hooks": {
"PreToolUse": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "cd \"$CLAUDE_PROJECT_DIR\" && \"$CLAUDE_PROJECT_DIR/.venv-uv/bin/python\" \"$CLAUDE_PROJECT_DIR/infrastructure/code-standards/hooks/prevent_violations.py\""
}
]
}
]
}
}
Hope this helps you get unblocked!
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
I just tested this issue on Claude Code v2.0.61 (macOS Darwin 25.1.0) and can confirm that PreToolUse and PostToolUse hooks are now working correctly.
Test Setup
{
"hooks": {
"PreToolUse": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "echo \"$(date +%H:%M:%S) PreToolUse: $(cat | jq -r '.tool_name')\" >> /tmp/hook-test-pre.log"
}
]
}
],
"PostToolUse": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "echo \"$(date +%H:%M:%S) PostToolUse: $(cat | jq -r '.tool_name')\" >> /tmp/hook-test-post.log"
}
]
}
]
}
}
Results
| Tool | PreToolUse | PostToolUse |
|---|---|---|
| Read | ✅ Working | ✅ Working |
| Write | ✅ Working | ✅ Working |
| Bash | ✅ Working | ✅ Working |
| Edit | ✅ Working | ✅ Working |
All hooks fired correctly and logged the expected tool names to the log files.
Notes for Anyone Still Experiencing Issues
-
Hooks must read from stdin - The JSON payload is piped to stdin, not passed as environment variables (
$TOOL_NAME). Usecat | jq -r '.tool_name'to extract the tool name. -
Session restart required - Hook changes don't take effect mid-session. Either run
/hooksto apply changes or restart Claude Code. -
Version matters - Make sure you're on a recent version (
claude --version).
This issue appears to be resolved as of v2.0.61.
This issue still persists and is a major security loophole.
Environment
- Claude Code Version: 2.0.76
- Platform: macOS (Darwin 24.6.0)
-
Hook Config: PreToolUse with
matcher: "*"in~/.claude/settings.json - Binary: Custom hook handler that enforces file access policies
Configuration
{
"hooks": {
"PreToolUse": [{
"matcher": "*",
"hooks": [{
"type": "command",
"command": "/Users/<user>/.local/bin/securityCheck",
"args": ["--hook-check"],
"timeout": 30
}]
}]
}
}
- Hooks configured in ~/.claude/settings.json (user-level)
- Session restarted after configuration changes (per official hooks guide)
- No project-level settings conflicts (verified .claude/settings.json is empty)
- Removed permissions block from .claude/settings.local.json to avoid Issue #14082
- Valid JSON configuration verified with jq
Observed Behavior
✅ Manual Test (Hook Binary Works)
echo '{"session_id":"test","tool_name":"Read","tool_input":{"file_path":"~/.agentfence/secrets/agentfence-secret.txt"}}'
| /Users/
Output: {"permissionDecision":"deny",...} Hook correctly blocks access
⚠️ Hooks ARE Loading (Partial Evidence)
Critical finding: Hooks ARE being invoked for Bash commands, but NOT for Read/Write/Edit tools.
When running Bash commands in the session, Claude Code output shows: ⏺ Bash(echo "test") ⎿ PreToolUse:Bash hook error
This "PreToolUse:Bash hook error" message appears consistently for Bash tool usage, proving:
- ✅ Hooks configuration is loading correctly
- ✅ Hook system is active and attempting to run
- ❌ Hooks fire for some tools (Bash) but NOT others (Read, Write, Edit)
This suggests selective tool coverage, not a configuration issue.
❌ Actual Usage (Hook NOT Invoked for Read/Write Tools)
Test 1: Asked Claude to read protected file Result: File read successfully, contents displayed Evidence: No hook log entry at timestamp of Read operation
Test 2: Explicitly requested native Read tool Result: File read successfully, secrets exposed Evidence: No hook invocation logged
Test 3: Used MCP tool (alternative) Result: Correctly blocked via MCP server Evidence: MCP goes through daemon, native tools bypass completely
| Action | Tool Used | Hook Invoked? | Result |
|---|---|---|---|
| Manual test | CLI | ✅ Yes | BLOCKED correctly |
| Auto read | MCP read_file | ✅ Yes (via MCP) | BLOCKED correctly |
| Explicit read | Native Read | ❌ NO | BYPASSED - secrets read |
Security Implications
- Secrets Protection Broken - Hook configured to block ~/.securityCheck/secrets/**, **/.env, ~/.aws/credentials - Native Read tool bypasses all protection - Secrets accessible despite policy configuration
- Trivial Bypass - User/agent can simply request "use native Read tool" - No hook invocation = no enforcement - Security tools built on hooks are non-functional
- Enterprise Use Cases Blocked - Can't build reliable access control - Can't enforce organizational policies
Root Cause Analysis
Two-layer failure:
- Hook trigger mechanism broken - Hook binary works when called directly but Claude Code never invokes it for native tools
- No fallback enforcement - When hook fails to run, operation proceeds. It Should fail-closed (deny by default) but currently fails-open (full access)
Workaround
Using MCP layer instead:
- MCP tools (read_file, execute_command) go through daemon
- Successfully enforce policies
- BUT: Easily bypassed by requesting native tools
- Not a security boundary, just a preference
Ask
For Anthropic Team:
- Priority: This blocks security tooling built on Claude Code
- Diagnosis: Can you confirm if hook triggers are disabled for certain tools (Read, Write, etc.)?
- Timeline: Any ETA on fix for hook system?
For Community:
Has anyone successfully gotten PreToolUse hooks working for Read/Write/Edit tools in 2.0.76? If so, what's your configuration?
Reproduction Steps
- Create hook handler that logs to file and returns permissionDecision: "deny"
- Configure in ~/.claude/settings.json with matcher: "*"
- Remove any permissions block from local settings (Issue #14082)
- Restart Claude Code
- Ask Claude to read any file
- Observe: File read succeeds, no hook log entry
Expected: Hook invoked, file access denied Actual: Hook not invoked, file access succeeds
PretoolUse hook is not working for me too -
{ "hooks": { "PreToolUse": [ { "matcher": "Read|Grep", "hooks": [ { "type": "command", "command": "node $PWD/hooks/read_hook.js" } ] }, { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "node $PWD/hooks/query_hook.js", "timeout": 300 } ] }, { "matcher": "", "hooks": [ { "type": "command", "command": "jq . > pre-log.json" } ] } ], "PostToolUse": [ { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "jq -r '.tool_response.filePath // .tool_input.file_path // empty' | xargs -I {} npx --yes prettier --write {} 2>/dev/null || true" }, { "type": "command", "command": "node $PWD/hooks/tsc.js" } ] }, { "matcher": "", "hooks": [ { "type": "command", "command": "jq . > post-log.json" } ] } ] } }
I had hooks working correctly as of last night, but now I get PreToolUse:Edit hook error with no meaningful error information. The worst part is I have this hook in place as a security precaution, and claude is just continuing on without actually running the hook rather than stopping out of safety.
By the way, this also happens on Claude Code on the web
@bcherny Any chance we could get the team to look at this - 4 months old now.