Feature Request: AssistantResponse Hook

Resolved 💬 3 comments Opened Jan 13, 2026 by samfreeman Closed Mar 5, 2026

Summary

Add a new hook event AssistantResponse that fires when Claude outputs a response, enabling external tools to observe, log, and act on the complete conversation in real-time.

Problem

Currently, Claude Code provides hooks for:

  • UserPromptSubmit - when user sends a message
  • PreToolUse / PostToolUse - when tools are called

But there's no hook for when Claude responds. This makes it impossible to build tools that need visibility into what Claude says without resorting to file watching (polling the transcript.jsonl file).

Use Cases

1. Logging & Auditing

Teams need conversation logs for compliance, debugging, and training. Currently requires parsing transcript files after the fact.

2. Analytics & Monitoring

Track what Claude produces, measure response quality, identify patterns, monitor for issues in real-time.

3. Integration & Automation

Pipe responses to Slack, email, ticketing systems, or trigger workflows based on Claude's output.

4. Custom Interfaces

Display responses in dashboards, web apps, IDE panels, or other UIs beyond the default terminal/VS Code.

5. Accessibility

Enable screen readers, alternative output formats, or assistive technologies to receive responses.

6. Team Visibility

Let team members observe Claude Code sessions without terminal access - useful for pair programming, code review, or training.

Proposed Solution

Add AssistantResponse hook event that fires when Claude completes a response.

Hook Input (via stdin JSON)

\\\json
{
"hook_event_name": "AssistantResponse",
"session_id": "string",
"transcript_path": "string",
"response": "string",
"cwd": "string"
}
\
\\

Configuration

\\\json
{
"hooks": {
"AssistantResponse": [
{
"hooks": [
{
"type": "command",
"command": "/path/to/handler.sh"
}
]
}
]
}
}
\
\\

Benefits

  • Enables real-time conversation observability
  • No file watching/polling needed
  • Consistent with existing hook architecture
  • Low implementation overhead (event already exists internally)
  • Completes the conversation lifecycle (user input → tool use → assistant response)

Alternatives Considered

  1. Polling transcript.jsonl - Works but inefficient, platform-dependent (fs.watch behavior varies across OS/WSL), and feels like a workaround
  2. MCP-based approach - Requires Claude to actively push messages via tool calls, which is unreliable (Claude drifts from instructions over long sessions)

Additional Context

With UserPromptSubmit and AssistantResponse, developers would have complete conversation visibility. This enables a whole ecosystem of Claude Code companion tools - loggers, dashboards, integrations, accessibility tools, and more.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗