[FEATURE]: Show per-part timestamps for thinking, tool calls, and tool output in the TUI #42498

Activity

1. github-actions

   assigned

   kommander

   on Aug 14, 2026
2. github-actions commented on Aug 14, 2026

   

   github-actionsBot

   on Aug 14, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Show timestamp and duration on tool execution blocks #22144: "Show timestamp and duration on tool execution blocks" — closed with no implementation landed, nearly identical request for per-block timestamps on tool execution
   • [FEATURE]: Show message/run start and completion timestamps with millisecond precision #35348: "Show message/run start and completion timestamps with millisecond precision" — open, and per the comments there, explicitly requests per-step timestamps (you already cite this one)
   • [FEATURE]: TUI: timestamp gutter mode for messages #29399: "TUI: timestamp gutter mode for messages" — closed, covers overlapping rendering-layer timestamp work in the TUI

   If this is intentionally a narrower or differently-scoped follow-up to those issues, it would help to clarify what specifically is new beyond what was tracked in #22144 and #35348.
3. Nowaker commented on Oct 7, 2026

   

   Nowaker

   on Oct 7, 2026

   More actions

   A design for this, implemented in the PR linked below.

   Today the transcript can show a time in two places only: under a prompt (/timestamps) and, with #53195, in the assistant turn footer (turn_timing.time, /turn-times). Thinking blocks, tool calls, text blocks, error boxes and the compaction divider never do. The tool and reasoning parts already carry time.start/time.end, so this is a TUI-only change.

   Proposal: one timestamps option in tui.json that names the transcript entries showing a timestamp.

   • "all", "none", a comma-separated list ("user,tool"), or an array (["user", "tool"]).
   • Types: user, assistant, text, reasoning, tool, error, compaction.
   • Each part shows when it finished rather than when it started, because a finished time plus a duration tells you both: tool calls show end · duration, thinking blocks put the time before their existing duration.
   • Same format as feat(tui): show per-turn completion time and duration #53195: time of day if today, otherwise the date then the time.

     ┃  run the steps
     ┃  8:04 PM
        + Thought: 8:05 PM · 359ms
        Looking around first.
        8:05 PM
        ✱ Glob "*" (1 match) · 8:05 PM · 500ms
     ┃  $ echo hello
     ┃  hello
     ┃  8:05 PM · 666ms
        ▣  Build · Fake · 8:05 PM
   

   Compatibility: unset is the default and changes nothing. /timestamps, /turn-times and turn_timing.time work and persist exactly as now. Once set, the list decides every type on each start and overrides turn_timing.time. /timestamps and /turn-times still flip prompt and turn times, but only until the TUI exits. If the kv value won instead, the option would do nothing on most existing installs: kv.json usually already holds "timestamps", because the kv store writes its in-memory defaults along with any other write.

   A stall shows as a running tool with no timestamp yet. I did not add a live "running since" clock; #50891 covers elapsed time for running calls.
4. Nowaker

   added 2 commits that reference this issue on Oct 7, 2026

   docs(forklog): record per-entry transcript timestamps

   ...

   1268103

   docs(forklog): record per-entry transcript timestamps

   ...

   ac63095
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed request, @ImBIOS! As I understand it, you'd like each part in the TUI (thinking blocks, tool calls and tool output headers) to show its own start time when timestamps are enabled, not just the time under each message, so stalls are easy to spot and activity can be matched against commits and CI logs.

   One note: the /timestamps toggle (session.toggle.timestamps) is from OpenCode v1 (opencode-ai, 1.x). The v2 TUI (@opencode/cli, 2.x) doesn't have a timestamp toggle yet, so in v2 this would also mean adding that toggle. The current TUI plugin API has no slot for individual parts in the session view, so a plugin can't add this for now.

   Maintainers will consider it. Related issues:

   • [FEATURE]: Show timestamp and duration on tool execution blocks #22144: timestamp and duration on tool execution blocks (closed for inactivity, never implemented)
   • [FEATURE]: Show message/run start and completion timestamps with millisecond precision #35348: start and completion timestamps for runs; its comments ask for per-step timestamps
   • [FEATURE]: Show timestamp on permission prompts (Ask/Approve dialogs) #42124: timestamps on permission prompts
6. Josef-Le commented on Nov 1, 2026

   

   Josef-Le

   on Nov 1, 2026

   More actions

   +1. Please cover both individual tools and each assistant response, including intermediate responses that end in tool calls. Related assistant-turn request: #53192.

   Item	Proposed display
   User message	Sent · 14:02:11
   Assistant response	Assistant · 14:02:12 → 14:02:15 · 3.4s
   Tool call	shell · 14:02:13 → 14:02:14 · 1.2s
   Running call	shell · 14:02:13 · running; show finish and duration when it completes
   Controls	Boolean config setting, /timestamps, command-palette toggle, and configurable keybind

   Use compact, dimmed local HH:MM:SS times and compute durations from stored millisecond values, including across midnight. Keep existing behavior when disabled. When enabled, individual tool timing should remain visible rather than disappearing into collapsed groups. Persist the toggle in configuration so restarts retain the choice.

   This makes it possible to correlate activity with logs and distinguish a queued tool from a running or completed tool without exporting a session.

   🤖 Authored by an agent on behalf of @Josef-Le.