claude-code - 💡(How to fix) Fix Allow hooks to spawn Monitor or invoke tools directly [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49431Fetched 2026-04-17 08:41:23
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
commented ×2labeled ×2closed ×1

Code Example

{
  "tools": [
    {
      "name": "Monitor",
      "input": {
        "command": "bash ~/.claude/skills/watch-pr-checks/scripts/poll-checks.sh 123",
        "description": "PR #123 CI checks",
        "persistent": true,
        "timeout_ms": 3600000
      }
    }
  ]
}
RAW_BUFFERClick to expand / collapse

Feature Request: Allow hooks to spawn Monitor (or invoke tools)

Problem

Today, hooks can only output text that becomes system reminders. If a hook detects a meaningful event (e.g. git push to a branch with an open PR), the only way to start background monitoring is through an indirect pipeline:

  1. Hook outputs a reminder
  2. Claude reads the reminder
  3. Claude invokes a skill
  4. The skill tells Claude to call Monitor

This works but has friction: it depends on Claude interpreting the reminder correctly every time, it consumes context window, and the user has no guarantee the Monitor actually starts.

Proposed Solution

Allow hooks to return a structured response that directly spawns a Monitor (or more generally, invokes a tool). For example, a PostToolUse hook could return:

{
  "tools": [
    {
      "name": "Monitor",
      "input": {
        "command": "bash ~/.claude/skills/watch-pr-checks/scripts/poll-checks.sh 123",
        "description": "PR #123 CI checks",
        "persistent": true,
        "timeout_ms": 3600000
      }
    }
  ]
}

Use Case

I built a watch-pr-checks skill that monitors GitHub CI checks for the current PR via Monitor. A PostToolUse hook detects git push and gh pr create and should automatically start the monitor. Today the hook can only suggest that Claude start the monitor; it can't guarantee it.

This pattern generalizes: any hook that wants to start a background watcher, trigger a build, or kick off a long-running process after detecting a specific event would benefit from direct tool invocation.

Alternatives Considered

  • Hook reminder → Skill → Monitor: Current approach. Works but is indirect and fragile.
  • Hook starts a background process directly: The process runs outside Claude's context, so Monitor notifications don't reach the conversation.

extent analysis

TL;DR

Allow hooks to return a structured response that directly invokes a tool, such as Monitor, to reduce friction and guarantee the tool starts.

Guidance

  • Consider modifying the hook response format to include a "tools" array, as proposed, to enable direct tool invocation.
  • Evaluate the feasibility of implementing a new hook interface that accepts the proposed structured response.
  • Investigate potential security implications of allowing hooks to spawn arbitrary tools or processes.
  • Assess the compatibility of this change with existing hook implementations and Claude's skill ecosystem.

Example

{
  "tools": [
    {
      "name": "Monitor",
      "input": {
        "command": "bash ~/.claude/skills/watch-pr-checks/scripts/poll-checks.sh 123",
        "description": "PR #123 CI checks",
        "persistent": true,
        "timeout_ms": 3600000
      }
    }
  ]
}

This example illustrates the proposed structured response format for direct tool invocation.

Notes

The implementation of this feature may require significant changes to the hook interface and Claude's internal logic. Additionally, the security implications of allowing hooks to spawn arbitrary tools or processes must be carefully considered.

Recommendation

Apply workaround: Implement the proposed structured response format for hooks to invoke tools directly, as it addresses the current friction and fragility in the system. This approach provides a more direct and reliable way to start background monitoring or other long-running processes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Allow hooks to spawn Monitor or invoke tools directly [2 comments, 2 participants]