claude-code - 💡(How to fix) Fix Add per-tool-call wall-clock timestamps on tool-use headers in the VSCode extension chat UI [1 participants]

Request

Add a setting (e.g., showToolCallTimestamps) that renders the actual wall-clock execution time inline on each tool-call header in the VSCode extension chat UI. Distinct from existing message-level timestamp requests (#24349, #44763) — those address per-message annotations; this asks for per-tool-call granularity.

Use case

When debugging long-running sessions (orchestrators, CI watching, multi-step pipelines), it's hard to reconstruct timing from the chat alone. Knowing precisely when each tool fired is the cheapest signal for "how long did the LLM spend thinking before that Bash call?" / "did the user-approve gate add 30s or 5min here?" / "where did the cumulative latency go?".

What's already been tried (empirically, on extension version 2.1.123)

1. PreToolUse hook emitting systemMessage with matcher * and a script that outputs {"systemMessage":"[HH:MM:SS UTC] <ToolName>"}. Hook fires reliably (confirmed via sidecar log file accumulating one entry per tool call), but the VSCode extension does not visibly render the systemMessage for pure pass-through hooks (no permissionDecision). May be related to the systemMessage rendering regressions tracked in #9090 and #50542.

2. Settings keys showMessageTimestamps and showTurnDuration (both present in the local extension's claude-code-settings.schema.json but not in the official code.claude.com/docs/en/settings page). Set both to true, fully restarted the extension via a fresh VSCode window. Neither produces any visible rendering in the chat UI — no per-message timestamps, no "Cooked for Nm Ns" annotation. Schema documents them; extension does not implement them.

3. Manual description-field prefix by the model — produces visible inline output but is model-estimated (no live clock available to the LLM), drifting by minutes during long sessions and even being timezone-confused if the model conflates user local time with UTC.

So, in 2.1.123, no user-side mechanism produces precise wall-clock timestamps on tool-call headers.

Suggested scope (in priority order)

1. Primary ask — render wall-clock execution time on each tool-call header in the VSCode extension chat UI, gated on a new showToolCallTimestamps setting (or whatever spelling fits the schema).
2. Secondary ask — implement the existing showMessageTimestamps and showTurnDuration keys in the VSCode extension UI, since they're documented in the bundled schema but currently inert.
3. Tertiary ask — fix or document the PreToolUse systemMessage render path for pass-through hooks. Keeping that channel functional gives users an escape hatch for any timestamp / annotation use case the team doesn't ship natively.

Related

• #24349, #44763 — message-level timestamp requests (related but message-level, not tool-call-level)
• #9090, #50542 — systemMessage render regressions in other surfaces

Environment

• VSCode extension version: 2.1.123 (win32-x64)
• VS Code: 1.94+
• Plan: Team (OAuth subscription)
• Verified across multiple project workspaces; behavior is consistent.