[FEATURE] tool_result_delta event in stream-json for live tool output
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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗