[Bug] PreToolUse hook with additionalContext causes model turn to terminate on tool error
Bug Description
When a PreToolUse hook outputs additionalContext via hookSpecificOutput, and the subsequent tool call returns a non-zero exit code, the model's turn terminates immediately without responding to the error. The model never gets a chance to process the failure and continue.
Repro:
- Add a PreToolUse hook in
.claude/settings.local.json:
{
"hooks": {
"PreToolUse": [
{
"hooks": [
{
"type": "command",
"command": "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"additionalContext\":\"Current
time: 2026-01-01\"}}'"
}
]
}
]
}
}
- Start a conversation and ask the agent to run:
bash -c 'exit 1' - Observe: the model's turn ends immediately after the error. It does not respond or attempt recovery.
Expected: The model receives the error result and continues its turn (responds to the error, tries alternatives, etc.) — same as when no PreToolUse hook is configured.
Actual: The turn silently terminates. In longer autonomous workflows, this manifests as the model stopping without being able to respond to the failed tool call, and requires user prompting to continue.
Workaround: Remove the PreToolUse hook.
Environment: Claude Code CLI, claude-opus-4-6, macOS Darwin 24.5.0
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.69
- Feedback ID: 5677cd3e-ed07-4620-a851-3ac75698a58e
Errors
[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/$USER/.local/share/claude/versions/2.1.69 (expected in multi-process scenarios)\n at NS_ (/$bunfs/root/src/entrypoints/cli.js:2397:2066)\n at zpR (/$bunfs/root/src/entrypoints/cli.js:2397:1210)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-03-05T01:46:44.267Z"}]
4 Comments
PreToolUse hooks should return
permissionDecision, notadditionalContext:Use
systemMessagefor PreToolUse context:Still relevant as of Claude Code 2.1.86. Related to #40671 — same pattern of unexpected turn termination triggered by different tool/hook interactions.
This issue was fixed as of version 2.1.110.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.