feat(core): run Claude Code tool hooks - #52765

Issue for this PR

Refs #12472

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Runs the PreToolUse, PostToolUse and SessionStart command hooks from ~/.claude/settings.json and settings.local.json, next to the existing .claude skills compatibility.

It is an internal plugin on the existing tool execute.before / execute.after hooks. Each matching hook gets the Claude Code payload on stdin (session_id, cwd, hook_event_name, tool_name, tool_input, tool_use_id, plus tool_response after the call). Tool names are mapped to Claude Code's (shell -> Bash, edit -> Edit, ...) and tool_input gets file_path / old_string / new_string added beside the native keys, so existing matchers and scripts keep working.

• PreToolUse exit 2 fails the call with stderr as the tool error.
• PreToolUse exit 0 with JSON hookSpecificOutput.permissionDecision: deny fails the call with permissionDecisionReason, ask shows the normal permission prompt for the call even when rules would allow it (a rule that denies still wins). The older top-level decision: "block" form counts as deny. allow is ignored on purpose, so a hook can tighten permissions but not loosen them.
• PostToolUse exit 2 appends stderr to the tool result. Exit 0 with JSON decision: "block" + reason, or hookSpecificOutput.additionalContext, appends that text the same way.
• When several hooks match, a deny from any of them wins over an ask.
• The ask reason is the permission request message. The TUI permission prompt now shows a request's message under its title (before, only the attention notification did), with a render test in test/cli/tui/input-scope.test.tsx.
• SessionStart runs when a session is created (not for subagent sessions), with source: "startup" for the matcher. Its output, either hookSpecificOutput.additionalContext or plain stdout, is saved to the session as a synthetic message. A first request that starts before the hooks finish waits for them and gets the context directly.
• Any other exit code, a timeout, or a hook that fails to start is logged and does not block the tool.

What this leaves out, on purpose:

• Stop. There is no hook on v2 that can keep the loop going, which is [FEATURE]: add session.stopping plugin hook to allow re-entering the agent loop #16626.
• Hooks from a project's .claude directory. They would run commands from a repo the user has not reviewed, and I did not want to add a trust prompt in this PR. Only the home directory settings are read.
• SessionStart with source resume, clear or compact. Only new sessions run it.

How did you verify your code works?

• Tests in test/config/claude-hooks.test.ts run real hook commands from a temp .claude directory: exit 2 blocks with stderr, the stdin payload matches, exit 0/1 and non-matching matchers let the call through, settings.local.json is read, project .claude hooks are ignored, PostToolUse feedback is appended, a JSON deny blocks with its reason, and a JSON ask goes through Permission.assert (the evaluate hook turns allow into ask, keeps deny, and leaves other requests alone; a reject with feedback fails the call with that feedback), and SessionStart output is saved to a new top-level session, skipped for subagents, and spliced into a first request that started before it was saved.
• bun typecheck in packages/core is clean, and the repo pre-push bun run check passes.
• The tests drive the plugin through a stub plugin host and a stub Permission service, the same way the other internal plugin tests do. I have not run it in a live session.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR