PostToolUse hooks with additionalContext not surfacing for MCP tool calls

Status Closed — not planned

Maintainer reply ✓ Yes — localden

Activity 11 comments · opened Feb 10, 2026 · closed Jun 1, 2026

💡 Likely answer: A maintainer (localden, collaborator) responded on this thread — see the highlighted reply below.

Description

PostToolUse hooks that output JSON with additionalContext and exit 0 produce no visible output when triggered by MCP tool calls. The hook scripts work correctly when tested manually (piping JSON stdin and checking stdout), but no additionalContext is injected into the conversation after MCP tool execution.

Reproduction

{
  "PostToolUse": [
    {
      "matcher": "mcp__mcp-task-orchestrator__manage_container",
      "hooks": [
        {
          "type": "command",
          "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/test-hook.sh",
          "timeout": 5
        }
      ]
    }
  ]
}

Hook script outputs valid JSON:

{
  "hookSpecificOutput": {
    "hookEventName": "PostToolUse",
    "additionalContext": "New MCP task created: [abcd1234] My Task. Create a CC mirror task..."
  }
}

Script exits with code 0.

Call the MCP tool (e.g., create a task via manage_container)

Expected: additionalContext is injected into the conversation as context for the model
Actual: No hook output appears. Tool result shows only the MCP server response.

Verification

Script tested manually with echo '<json>' | bash script.sh — produces correct JSON output, exits 0
Tested with hooks registered both via plugin session-hooks.json and directly in .claude/settings.local.json
Tested across session restarts (hooks load fresh at startup)
TaskCompleted hooks DO work using stderr + exit 2 pattern on the same MCP tool results — confirming hook matching/registration is functional

Affected hook types

All PostToolUse hooks matching MCP tools with additionalContext output:

create-mirror-prompt.sh → mcp__*__manage_container
mirror-bootstrap-prompt.sh → mcp__*__get_next_task
status-sync.sh → mcp__*__request_transition

Environment

Claude Code CLI (latest)
Windows (MSYS_NT / Git Bash)
MCP server running via Docker (stdio transport)
Plugin hooks registered via .claude-plugin/plugin.json → session-hooks.json

View original on GitHub ↗

11 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

jpicklyk · 6 months ago

Additional Context — Related Issues

After further investigation, this appears to be part of a broader pattern:

#12151 — Plugin hook output not captured or passed to agent (root issue, 18+ comments). Covers plugin-based hooks across SessionStart, UserPromptSubmit, and PostToolUse. Comments confirm it also affects non-plugin hooks in some configurations.
#18427 — PostToolUse hooks cannot inject context visible to Claude. Confirms that additionalContext, systemMessage, modifyResult, and plain stdout all fail to surface for PostToolUse hooks on any tool type (not just MCP).
#16538 — Plugin SessionStart hooks don't surface additionalContext to Claude.

Key Distinction

Our original report focused on MCP tools specifically, but #18427 demonstrates that PostToolUse additionalContext doesn't work for any tool type. The MCP-specific aspect compounds this because:

The PreToolUse updatedInput workaround from #18427 (appending context to Bash commands) cannot apply to MCP tool calls — there's no shell command to modify
TaskCompleted hooks (stderr + exit 2 blocking) DO work for MCP tools — confirming the hook matching and execution pipeline is functional; only the additionalContext injection path is broken

Impact

This blocks an entire category of plugin automation: hooks that need to advise the agent based on tool results (e.g., prompting mirror task creation after MCP task creation, suggesting next actions after status transitions). The only working hook-to-agent communication path for MCP tools is the blocking pattern (exit 2), which is inappropriate for advisory prompts.

prodan-s · 6 months ago

Related data point: we confirmed PostToolUse additionalContext works for all native tools (Grep, Glob, Write, Edit) on v2.1.45 using non-plugin hooks in ~/.claude/settings.json. This suggests the issue in this report is specific to MCP tool calls (and/or plugin-defined hooks), not a general PostToolUse pipeline failure.

Our hooks use {"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":"..."}} with exit 0.

Additional note: tool_response in PostToolUse stdin is a JSON object (e.g., {"mode":"files_with_matches","filenames":[],"numFiles":0} for Grep), not the display string — relevant for hook authors writing pattern matchers.

cdr-x · 5 months ago

Don't ignore this bug, please please fix this! PostToolUse using additionalContext does not work when triggered by an MCP tool call.

prodan-s · 5 months ago

This issue remains critical for our workflow. Empirically confirmed on v2.1.81 (Mar 15 + Mar 21, 2026):

Native CC tools (Grep, Glob, Write, Edit): additionalContext via hookSpecificOutput wrapper works correctly on PostToolUse.
MCP tools (Slack, Playwright, Linear): Same hook, same output format — hook fires (visible in logs), but the model never receives the injected context. Silently dropped.

We have 6 PostToolUse hooks affected. The workaround (exit 2 + stderr, or decision: "block" + reason) works but loses the non-blocking advisory injection pattern.

This is the most impactful open hook infrastructure bug for anyone with MCP-heavy setups. Would appreciate any update on whether this is being tracked internally.

prodan-s · 4 months ago

Still affecting our production setup on v2.1.107 (macOS, Teams plan, 7 MCP servers via stdio + HTTP). We have 6 PostToolUse hooks that match MCP tools — all silently lose their additionalContext injection. Current workaround: using exit-2-stderr pattern for critical hooks on MCP tools, but this only works for PreToolUse deny (not PostToolUse context injection).

This also interacts with #42702 (stdin contention when multiple PreToolUse hooks match same tool) — both bugs reduce the reliability of the hook pipeline for MCP integrations.

Would be helpful to know if this is on the roadmap or if there's a known architectural reason MCP tools handle hook output differently than built-in tools.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

localden collaborator · 2 months ago

We investigated this and added a regression test confirming PostToolUse additionalContext reaches the API for MCP tools the same as native tools. The hookResults attachment loop runs after the MCP/native branch, so there is no MCP-specific drop. If you still see additionalContext missing on a current version, please open a new issue with claude --version, your hook config, and --debug output.

prodan-s · 2 months ago

Confirming fixed for our setup: tested today on v2.1.174 (macOS, settings.json-registered PostToolUse hooks) across MCP stdio and HTTP transports plus a native-tool control — every arm's additionalContext reached the model (transcript shows the hook_additional_context attachment for each MCP call; model echoed the injected sentinels). Not retested: the original Windows/plugin-registered-hook path and SSE.

Also correcting my Apr 14 comment: "still affecting v2.1.107" was not based on a fresh runtime test — our own Mar 28 retest had already found this working on v2.1.85. So for our setup: failing through v2.1.81, working from v2.1.85 onward.

Thanks @localden for the regression test. If you're still hitting this, re-test on a current build before keeping an exit-2/stderr workaround; if it persists, open a new issue with claude --version, hook config, and --debug output.

github-actions[bot] · 17 days ago

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.