[FEATURE] tool_result_delta event in stream-json for live tool output

Resolved 💬 3 comments Opened May 30, 2026 by Danford Closed Jul 2, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When consuming Claude Code's --output-format stream-json, assistant text streams incrementally via content_block_delta, but tool_result blocks arrive as a single atomic event only after the tool finishes.

For fast tools (Read, Edit, Glob) this is fine. For Bash it's a UX cliff. A 30-second npm install, a multi-minute build, or a long test suite produces output the entire time — but consumers of stream-json see nothing until the command exits.

This means:

  • Operators can't distinguish a stalled process from a slow one.
  • Errors printed early in a long command don't surface until the command completes.
  • Any UI or pipeline wrapping Claude Code has to show a blank spinner during the exact moments users most want feedback.
  • The CLI already has the bytes. The protocol has a streaming primitive for assistant text but no equivalent for tool output — even though tool output is where the long waits actually happen.

Proposed Solution

Add a tool_result_delta event to stream-json, mirroring content_block_delta:

{
  "type": "tool_result_delta",
  "tool_use_id": "toolu_…",
  "delta": { "type": "text_delta", "text": "<partial stdout/stderr>" }
}

The existing atomic tool_result event is still emitted on completion, unchanged, and remains authoritative.

Consumer experience: subscribe to tool_result_delta keyed by tool_use_id, append each fragment to a live output view — the same pattern already used for assistant text deltas.

Scope: highest value on Bash and BashOutput. WebFetch would be nice. Fast tools (Read, Edit, Glob, TodoWrite) don't need it.

Implementation flexibility: chunk boundaries (char/line/time-batched), exact timing, and an optional stream: "stdout" | "stderr" field are all implementer's choice. Deltas for a single tool_use_id should arrive in order; concurrent tools can interleave freely.

Backward compatibility: fully additive. Consumers that don't handle the new event ignore it and continue to receive the atomic tool_result exactly as today.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

I'm building a web dashboard that wraps Claude Code and surfaces tool calls in a UI for operators to monitor. Assistant text streams in live and the experience is great — but when the agent runs a long Bash command (build, test suite, large install, deploy), the UI shows a frozen spinner for the entire duration because tool_result only arrives once the command exits.

The same operator running the same command in a terminal would see output streaming the whole time. Routing the work through Claude Code makes the live-feedback experience strictly worse, even though the CLI already has the bytes in its subprocess buffer.

A tool_result_delta event would let any dashboard, CI/CD wrapper, or other stream-json consumer render live tool output the same way it already renders live assistant text — closing the last big gap in the streaming protocol.

View original on GitHub ↗

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