[FEATURE] Surface tool-call request/response timestamps to the model so it can perceive elapsed time during long-running tools

Preflight Checklist

• [x] I have searched existing requests
• [x] This is a single feature request

Problem Statement

Claude Code injects no timing information into the model's context — not for user messages, and not for tool calls. The .jsonl transcript already records timestamps per API call and per tool result, but none of it reaches the model's reasoning. This creates two concrete, recurring failure modes:

1. The model can't tell a slow tool from a broken one.
When a tool call legitimately takes ~2 minutes (a slow DB query, a cold Lambda, a remote MCP gateway), the model has no perception that time is passing. From its point of view the request and response are adjacent tokens. So it has no basis to distinguish "this is just slow, keep waiting" from "something is wrong." In practice this leads the model to second-guess a healthy operation, assume a hang, or prematurely re-issue/abandon the call — when nothing was actually wrong.

2. Interrupts + queued messages collapse temporally.
While a tool call is in flight, the user often types follow-ups ("waiting long?", "?", "it took long?") and may then cancel with Esc. After the interrupt, those queued messages are presented to the model back-to-back with no timing, so the model treats them as if they were all sent simultaneously and reads none of them as "time has elapsed, the tool is taking a while." The temporal structure that would explain the user's growing impatience is entirely lost.

(Observed live: a remote MCP tool call sat pending; the user sent three impatience prompts over a couple of minutes and then interrupted. The model had no signal that real time had passed between any of them.)

Proposed Solution

Surface timestamps the harness already has into the model's context:

1. Tool-call request + response timestamps (and/or a computed duration_ms), so the model can reason: "this tool has been running 90s — normal for this tool, keep waiting" vs. "5s and still nothing, that's abnormal."
2. Per-user-message timestamps, so queued/interrupted messages carry their real arrival times and the model perceives the gaps between them.

Format could be lightweight (e.g. [+1m42s] deltas, or ISO 8601), and gated behind a setting / hidden from the UI to avoid clutter. The data already exists in the transcript — this is primarily about piping it into context.

Related (narrower, both closed/locked)

• #28502 — Model awareness of elapsed time between messages (closed, not-planned). Focuses only on user-message timestamps; a UserPromptSubmit + date hook workaround is noted there, but a commenter explicitly flags that it cannot reach tool-result timing.
• #32566 — Expose per-message timestamps to Claude's context (closed as duplicate of #28502, locked). Also user-message only.

This request adds the dimension those issues omit: tool-call request/response timing, which is what lets the model judge whether a long-running tool is healthy or stuck — and which no UserPromptSubmit hook can provide.

Priority

Medium–High — affects reasoning correctness during any long-running tool/MCP call.