Show timestamps on conversation messages

I built a plugin that addresses this as a workaround until native support lands:

claude-code-timestamps — adds a /timestamps command that displays a timestamped message timeline from your current session's transcript data.

--- Message Timeline ---

14:02  You     Can you refactor the auth module?
14:02  Claude  I'll start by reading the current auth implementation...
14:05  Claude  I've refactored the auth module. Here's what changed...
14:32  You     Looks good. Now add tests for the new token refresh logic.

• Uses HH:MM for same-day, YYYY-MM-DD HH:MM for older messages
• Reads existing transcript JSONL — no data collected, everything local
• Install: clone, add to settings.json, restart

A native UI integration would obviously be better, but this can help in the meantime.

this is beautiful. thank you!

Would this be something the Assistant could see? It would be helpful for Claude to know how long has elapsed between user messages. (e.g. I'm doing DNS work right now and it would be great for Claude to be able to factor into its reasoning, "It's been 3 hours and the TTL was set to 5 hours so we're still within the cache refresh time.")

Would really like this built-in as well, but another workaround for now is to add this to your CLAUDE.md:

- Prepend every assistant message with the current time in `h:mm` format (e.g., `3:07 `) before any other content. Obtain the time by running `date +%-I:%M` via the Bash tool at the start of each response — do not guess or infer it from context.

I have had scenarios where it would be beneficial to know when I prompted something. I would also like to add date + time, because I am a messy person who has too many chat tabs.

My agent said:

The timestamps would help me understand gaps in conversation.

+1 - Really useful for long-running sessions with background tasks (builds, deploys, CI). When multiple things run in parallel it's hard to correlate what happened when.

Currently working around this with a UserPromptSubmit hook that injects the current timestamp, but per-message timestamps in the UI would be much better.

A toggle in settings (e.g."showTimestamps": true) that adds a subtle timestamp next to each message/tool output would cover it.

Not quite what you're asking for (this doesn't render per-message timestamps in the transcript), but I made a plugin for the adjacent problem and it might scratch part of the itch. What you see:

• Live elapsed-time counter in the statusline since the model's last reply
• Visible [after 5m 2s] note when you send a prompt after >1 minute idle

The model itself also gets hidden timing context each turn (time, idle seconds, last-turn duration), so if you just want the model to be time-aware this covers that. If seeing the time in the transcript itself is what matters, a small Stop hook emitting a systemMessage with the timestamp would work too — the plugin uses the same mechanism for the idle note.

/plugin marketplace add clankercode/claude-inject-idle-time
/plugin install idle-timing@idle-info

Repo: https://github.com/clankercode/claude-inject-idle-time

Adding a web UI / iOS / multi-day-session perspective I don't see covered in the thread yet.

Not just the terminal TUI. This gap also exists on the web UI at claude.ai/code and in the Claude iOS app. Both render the chat as a vertical scroll with no timestamps on individual messages, so on multi-day sessions you can't tell when any given exchange happened. When this lands, please scope all three surfaces (CLI TUI + web + iOS), not only the CLI.

Real-world use. I run Claude Code sessions that span 3–7 days continuously (architecture firm, rolling project context with daily check-ins). A typical day mixes おはよう / 寝ます greetings, scheduled Routines, build triggers, and follow-ups. Scrolling back to "what did I ask on Tuesday?" is pure guesswork right now. Standard messaging apps (LINE, iMessage, Slack, WhatsApp) have shown per-message timestamps since around 2011 — this is baseline UX for anything people use as a conversation.

Workaround I'm running, as a concrete implementation example. I have Claude stamp every response itself via CLAUDE.md:

Every response must be bracketed with the current time, formatted as:
  受信 HH:MM JST   (at the very top of the response)
  応答 HH:MM JST   (at the very bottom of the response)

Procedure the model must follow:
- Before generating the response body, run `TZ=Asia/Tokyo date "+%H:%M JST"` and
  use that as 受信 (received ≈ user's send time).
- After the response body is complete, run `TZ=Asia/Tokyo date "+%H:%M JST"` again
  and use that as 応答 (replied).

This preserves per-message timing the way LINE does, so I can tell at a glance
when each exchange happened — even scrolling back through days of conversation.

Rendered output looks like:

受信 20:26 JST …response body… 応答 20:37 JST

It works once the model is instructed, but:

• It costs two shell calls per turn.
• The model silently forgets the rule on long sessions.
• It can't retroactively stamp older messages that were written before the rule was in place.
• When the sandbox clock drifts (I've seen 20-minute and 2-hour skews on different days), the self-stamped time is wrong too.

A platform-level timestamp — even just hover-to-reveal on each message — removes all of that friction in one change, and is ground-truth instead of model-reported.

Related but distinct. #47160 asks for exposing timestamps to the model (context layer). This issue is about displaying timestamps to the user (presentation layer) — both should land, but they're different fixes. My earlier #49692 tried to bundle them and was closed as a duplicate of #47160; I'm adding this perspective here rather than re-filing, since the UI layer is the concern of #44763.

For the model-facing side of this (Claude knowing what time it is), there's a working plugin workaround: claude-inject-idle-time — injects timing context via \UserPromptSubmit\ hook. I've opened a PR adding MCP time query tools and session timeline logging.

The UI timestamp display (what this issue specifically requests) still needs upstream support — can't render timestamps in the TUI from a plugin.

Mockup of how this could look in the TUI:

!timestamp-mock

Per-message timestamps (①) and tool durations (②) need upstream support. Idle gap indicator (③) and statusline clock (④) are achievable today via the idle-timing plugin.

cc @clankercode

I don't really care how you do it, but I would love for it to be a built-in to have timestamps on user prompts when they're submitted and when Claude hands back off to the user for input.

Community workaround: I combined two community plugins into a single fork that covers this: pleasedodisturb/claude-inject-idle-time.

Sourced from:

• clankercode/claude-inject-idle-time — passive time injection via hooks
• s-a-s-k-i-a/claude-code-timestamps (MIT) — retrospective transcript parsing

/timestamps 20

--- Message Timeline ---
14:32  You     can you refactor the auth middleware?
14:32  Claude  [tool: Read]
14:33  Claude  I'll restructure the middleware to separate...
14:38  You     looks good, now add tests

Also includes passive time injection (hooks), active time queries (MCP server), and a statusline elapsed timer.

Install: claude plugin add --from https://github.com/pleasedodisturb/claude-inject-idle-time

I too would LOVE this enhancement!

Timestamps and ability to copy messages are two very basic yet very needed features that are missing from CC for VS Code too. We really need this.

I'm adding to the request, using the VS Code Plugin and I'm missing it - for now I'm surviving with the global rule.

Until this is built in, here's a plugin that shows local-time [HH:MM:SS] on every message via a MessageDisplay hook — and can optionally make Claude itself time-aware: https://github.com/zoharbabin/claude-code-message-timestamps

/plugin marketplace add zoharbabin/claude-code-message-timestamps then /plugin install message-timestamps@zoharbabin-claude-tools — cross-OS, MIT. (see #2441)

Now I need to also merge Zohar's fix into my mixfix 😁😁

Update on the merged fork from April: it's now a standalone plugin, chronoclaude (v0.5.2, MIT), combining the pieces that surfaced in this thread plus one more:

• Visible [HH:MM:SS] on every assistant message, rendered in the TUI via the MessageDisplay hook (Claude Code 2.1.152+), adapted from zoharbabin/claude-code-message-timestamps. In April I wrote that per-message timestamps needed upstream support; the hook API has since made this possible from a plugin.
• /timestamps retrospective session timeline, from s-a-s-k-i-a/claude-code-timestamps (posted earlier in this thread)
• Hidden timing context for the model, idle-gap notes ([after 5m 2s]), MCP time tools, and a statusline clock, from clankercode/claude-inject-idle-time

Each surface toggles independently via CLAUDE_TIMING_* env vars (all on by default).

/plugin marketplace add pleasedodisturb/chronoclaude
/plugin install chronoclaude@chronoclaude

Timestamps on your own prompts still need upstream support; the hook can only decorate assistant messages.

cc @zoharbabin @s-a-s-k-i-a @XertroV

Came here to request the same feature 🙏 I think a timestamp for each line would be too busy.

Summary

Session history in Claude Code currently shows no time or date information. When resuming or scrolling back through a session, there's no way to tell when a given exchange happened — whether it was five minutes ago or three days ago.

Proposal

Borrow the familiar Slack/iMessage pattern: lightweight day dividers between messages from different days, plus a small timestamp on each message.

──────────── Tuesday, June 16 ────────────

  > my message
  10:42 AM

  Claude's response
  10:42 AM

  > my message
  2:15 PM

  Claude's response
  2:16 PM

──────────── Wednesday, June 17 ────────────

  > my message
  9:03 AM

Day dividers only appear when the day changes, so they add near-zero visual noise in a single continuous session but become genuinely useful across multi-day work.

Why it matters

• Makes long-running and resumed sessions far easier to navigate
• Helps reconstruct context ("what was I doing before lunch?")
• Useful when reviewing a session for debugging or sharing
• Low implementation surface, high day-to-day quality-of-life payoff

Notes

Timestamp density could be configurable (per-message vs. per-turn-cluster) if per-message feels too busy, but even a minimal version would be a clear improvement over the current zero-information state.

@ericmmartin have you tried any of the implementations above?

@pleasedodisturb Thanks for the pointer to chronoclaude — I switched from s-a-s-k-i-a/claude-code-timestamps based on your comment.

Quick feedback from a Windows user (Claude Code 2.1.165, VSCode extension + terminal TUI) — technical analysis done with the help of Claude Code itself:

• /timestamps works correctly via the py -3 launcher (not python3, which resolves to the Windows Store stub on Windows). Retrospective timeline displays cleanly in chat.
• MessageDisplay hook — inline [HH:MM:SS] timestamps do not appear in either the VSCode extension panel or the terminal TUI, despite npm install being run and the hook script producing correct output when called directly (node message-display.js with sample input returns the expected JSON with ANSI timestamp). No errors visible anywhere.

So to answer the question on #68538: chronoclaude partially solves it. The retrospective /timestamps surface works; the real-time inline timestamps don't — at least not on Windows. Not sure if this is a Windows-specific gap in the hook implementation or something else.

Happy to share more diagnostics if useful — further investigation will also be done with Claude's help, so replies may include additional technical detail as we dig deeper.

@Non-Dev-Contributor they should, try turning them on, all I did was combine all the existing workarounds and added a toggle for each feature (also made the inline timecode dark)

@pleasedodisturb Thanks for the pointer — I verified the toggles: CLAUDE_TIMING_MESSAGE_DISPLAY is not set (= on by default), node runs correctly, and message-display.js produces valid output when invoked directly. The other hooks (UserPromptSubmit, PreCompact, Stop) all fire correctly.

The MessageDisplay hook specifically does not fire. Setup: Claude Code 2.1.165, Windows 11, VSCode extension (not the terminal TUI). My suspicion is that MessageDisplay is implemented in the terminal/TUI but not in the VSCode extension panel on Windows. Can you confirm whether your setup is the VSCode extension or the terminal? If it's terminal-only, that would explain the gap.

@Non-Dev-Contributor weird, for me it works on 2 machines, but let me fix it now

<img width="1059" height="152" alt="Image" src="https://github.com/user-attachments/assets/fa28a546-02a3-44e5-ba26-007363553322" />

@Non-Dev-Contributor ah, I'll see if we can workaround this, but you're right

<img width="1067" height="430" alt="Image" src="https://github.com/user-attachments/assets/a3404450-dbbe-401a-9097-c66af13449e1" />

Can you test in terminal, just to be sure?

Update — v2 of claude-code-timestamps is out, reworked from the feedback in this thread:

• /timestamps timeline — day dividers + idle-gap markers (⋯ 4h 12m later ⋯), tool-call noise hidden by default, seconds/tools options. It locates the session transcript by the recorded working directory, fixing a case where paths containing spaces found nothing.
• **Live inline [HH:MM:SS] (experimental) on each assistant message via the MessageDisplay hook — it's display-only, so it costs 0 tokens**: the marker is drawn on screen but never enters the transcript or the model's context. Toggle with /timestamps inline on|off.
• Optional model time-awareness (the "how much time has elapsed" use case) via a UserPromptSubmit hook — off by default, so the plugin is token-free unless you opt in.
• All local, ground-truth times (no clock drift), MIT.

Install: /plugin marketplace add s-a-s-k-i-a/claude-code-timestamps → /plugin install chat-timestamps@chat-timestamps. Update later with /plugin marketplace update chat-timestamps + /plugin update.

@pleasedodisturb @pleasedodisturb Follow-up on the systemMessage diagnostic question: no, the idle note never appears in the VS Code panel — confirmed after multiple idle periods across parallel sessions today.

So the gap is wider than just MessageDisplay: the VS Code extension suppresses both hook output channels:

• MessageDisplay — event never dispatched by the panel
• systemMessage — hook fires correctly (we can confirm UserPromptSubmit runs), but the output is not rendered in the panel UI

This means CLAUDE_TIMING_STOP_TIMESTAMP=1 will also be dead on arrival for VS Code users — the Stop hook fires, but the systemMessage output goes nowhere visible.

Since neither channel works in the VS Code extension, this looks like a host-side gap worth a dedicated Anthropic issue rather than anything a plugin can work around. Happy to open one if that would help move it forward.

@pleasedodisturb @pleasedodisturb Update: MessageDisplay does work in the VS Code panel on 2.1.181 — confirmed working now. But there's a nuance worth noting:

It only works when the hook is registered directly in ~/.claude/settings.json, not when loaded via the plugin system (hooks/hooks.json in the plugin folder). Other hooks (UserPromptSubmit, PreCompact, Stop) load fine through the plugin, but MessageDisplay specifically does not get wired when coming from a plugin's hooks.json.

Workaround that works: add this directly to ~/.claude/settings.json:

"hooks": {
  "MessageDisplay": [{
    "hooks": [{
      "type": "command",
      "command": "node C:/Users/.../chronoclaude/scripts/message-display.js",
      "timeout": 10
    }]
  }]
}

Clean [HH:MM:SS] timestamps now appearing on every assistant message in the panel. Thanks for tracking this down — the 2.1.181 fix was the key piece.

@Non-Dev-Contributor @pleasedodisturb Consolidating the full diagnostic for the record, in case it helps other VS Code Windows users:

What was needed to get [HH:MM:SS] working in the VS Code panel:

1. Update to 2.1.181 — MessageDisplay is not dispatched by the VS Code panel on 2.1.165. Your fix was the key unlock.

1. Register MessageDisplay directly in ~/.claude/settings.json — even on 2.1.181, the hook does not fire when it comes from the plugin's hooks/hooks.json. All other hooks (UserPromptSubmit, PreCompact, Stop) load correctly through the plugin system; MessageDisplay specifically needs a direct entry:

``json
"hooks": {
"MessageDisplay": [{
"hooks": [{
"type": "command",
"command": "node /path/to/chronoclaude/scripts/message-display.js",
"timeout": 10
}]
}]
}
``

1. Set CLAUDE_TIMING_MESSAGE_DISPLAY_COLOR=none — without this, the panel renders the SGR escapes as literal text ([90m[13:20:16][0m). Your entrypoint-aware colour fix isn't on master yet, so this is the interim workaround.

After all three: clean [HH:MM:SS] on every assistant message in the VS Code panel. Two of the three steps are workarounds for things that should ideally be transparent — the plugin hook wiring gap in particular seems worth a separate issue if you're not already tracking it.

Resolved on the plugin side — shipped in chronoclaude v0.5.3 Full write-up since the thread got spread across a few comments:

What it actually was. The reported "no per-message timestamp in the IDE panel" was version-specific: MessageDisplay didn't fire in the VS Code panel on 2.1.165 (the build this was filed against), but it does on current builds (verified 2.1.181) — so that part looks fixed upstream in between. Testing in the actual panel then surfaced the real remaining bug: the plugin's grey [HH:MM:SS] marker emitted ANSI/SGR colour codes, and the VS Code panel renders those as literal [90m…[0m text instead of colour (a real terminal renders them fine).

The fix. Detect the client via CLAUDE_CODE_ENTRYPOINT (cli/unset ⇒ terminal ⇒ colour; claude-vscode, remote*, … ⇒ plain) and emit a plain [HH:MM:SS] marker on non-terminal surfaces. Colour still applies in real terminals (including VS Code's integrated terminal and the JetBrains terminal tool window). Verified end-to-end in the panel.

Update / install:

/plugin marketplace add pleasedodisturb/chronoclaude
/plugin install chronoclaude@chronoclaude

Two takeaways for anyone building on hooks:

• On current builds MessageDisplay fires in the VS Code panel; on 2.1.165 it didn't.
• The VS Code panel does not render hook systemMessage output at all, and renders ANSI escapes in displayContent as literal text. So a plugin's per-message UI has to go through MessageDisplay as plain text — systemMessage-based approaches don't show in the panel.

This is still a workaround — native per-message timestamps (this issue) would be the real fix, ideally scoped to web/iOS too. And I'm still after a JetBrains user to confirm rendering there: in the IDE terminal tool window, run printenv CLAUDE_CODE_ENTRYPOINT and check whether the marker shows as grey colour vs a literal [90m…[0m leak. Thanks all.

Calling any **JetBrains IDE** users (IntelliJ / PyCharm / WebStorm / GoLand) — I could use one quick test.

The colour fix above is verified in the VS Code panel, but I can't test JetBrains (don't have it). JetBrains runs Claude Code inside the IDE's terminal tool window, which is a real ANSI terminal, so the inline `[HH:MM:SS]` marker *should* render as grey with no `[90m…[0m` leak — but that's inferred, not confirmed.

If you have a JetBrains IDE, two things would close it out:
1. In the IDE's terminal tool window, run `printenv CLAUDE_CODE_ENTRYPOINT` and note the value.
2. Send any prompt and check the timestamp marker on the reply — grey colour, or a literal `[90m…[0m` leak, or no marker at all?

Reply with what you see and the entrypoint value. Thanks!

-----

cc @Non-Dev-Contributor @ericmmartin

Also, @s-a-s-k-i-a @zoharbabin @XertroV invited you as admins/collabs/owners to Chronoclaude, so may be we one day defork it into one thing (maybe yours:D)?

<img width="610" height="385" alt="Image" src="https://github.com/user-attachments/assets/c470834f-022d-4502-a974-6dce35e6caa6" />

@Non-Dev-Contributor thanks — that three-step breakdown is genuinely useful. Two notes:

• Step 3 (CLAUDE_TIMING_MESSAGE_DISPLAY_COLOR=none) is no longer needed as of v0.5.3. Colour is now auto-suppressed in the panel (entrypoint-aware), so a fresh install renders a clean [HH:MM:SS] with no config.
• Step 2 (MessageDisplay not wiring from the plugin's hooks/hooks.json) is the interesting one. On macOS the plugin-loaded MessageDisplay fired fine in the panel on 2.1.181 — so this looks host-side and possibly Windows-specific, rather than a plugin-manifest issue. A dedicated Anthropic issue is the right venue; if you open one I'll link it and add a Windows note to the README pointing at the manual-registration workaround in the meantime. Appreciate the thorough testing.

@pleasedodisturb @pleasedodisturb After updating to v0.5.3 and removing the direct settings.json hook entry (as the plugin-side fix implied it was no longer needed) — timestamps stopped working again after a full laptop restart.

Re-adding the direct settings.json MessageDisplay entry brought them back immediately, without even a VSCode restart.

So the plugin hook wiring gap persists in v0.5.3 on this machine: the plugin's hooks/hooks.json still does not wire MessageDisplay even after the update. The colour fix works (no [90m…[0m leak), but the hook registration via plugin system still doesn't fire for MessageDisplay specifically.

Setup for reference: Windows 11, VSCode extension 2.1.181, chronoclaude installed via plugins array in ~/.claude/settings.json (absolute path). The direct settings.json entry remains the working workaround — leaving it in place for now.

@Non-Dev-Contributor confirmed — thank you, that pins it down. Our hooks/hooks.json MessageDisplay entry is byte-identical in shape to UserPromptSubmit/Stop (which load fine via the plugin), so this is a host-side plugin-loader gap specific to the MessageDisplay event, not something the plugin can fix. On macOS the plugin-loaded hook does fire, so it looks Windows- or install-method-specific.

Two things done:

• Filed it upstream: #69380 (with your repro + setup credited).
• Documented the workaround in the chronoclaude README — register MessageDisplay directly in ~/.claude/settings.json to bypass the plugin loader, exactly as you found. Thanks for keeping at it through the restart re-test.

Feature request (VS Code extension): show date/time timestamps in the conversation view and the /resume picker

Environment: Claude Code VS Code extension (running inside VS Code, not the standalone terminal CLI).

When I resume an old session to understand when I did some work, there's no way to tell. The conversation view shows no timestamps, and the /resume picker only shows a relative time ("2 days ago"), not an absolute date. The data already exists — every line in the session .jsonl has an ISO-8601 timestamp — it's just not surfaced in the UI.

Requests

• (a) Show absolute start/last-activity dates in the /resume picker.
• (b) An option to display timestamps inline in the conversation view.
• (c) Times should display in the user's local PC timezone by default (the stored timestamps are UTC, so please convert for display rather than showing raw UTC).

Environment

• Claude Code VS Code extension version: <fill in>
• VS Code version: <fill in>
• OS: Windows 11