[FEATURE] Claude Cowork - Scheduled task run history entries should display timestamp instead of repeating task name

Resolved 💬 3 comments Opened Apr 13, 2026 by DiwakarVish Closed Apr 13, 2026

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

Description:
When a scheduled task has run multiple times, the sidebar shows a parent group (the task name) with child entries beneath it representing each individual run. Currently, every child entry inherits the same label as the parent task, making them completely indistinguishable from one another.

<img width="752" height="450" alt="Image" src="https://github.com/user-attachments/assets/0a90ad36-0167-483b-b833-29166d236f2a" />

Example of current behavior:
▼ 7am email scan
7am email scan ●
7am email scan ●
7am email scan
7am email scan
7am email scan
7am email scan
Expected behavior:
▼ 7am email scan
Apr 13, 2026 – 7:04am ●
Apr 12, 2026 – 7:03am ●
Apr 11, 2026 – 7:05am
Apr 10, 2026 – 7:04am

Why this matters:
The parent node already communicates what the task is. The child entries should communicate when each run occurred — that's the only information that makes them useful and distinguishable. Repeating the task name adds zero value and creates visual clutter that makes it impossible to identify or navigate to a specific run.

Proposed Solution

Replace the child entry label with the run's lastRunAt timestamp (already available in the task data), formatted in a human-readable local time format such as Apr 13, 2026 – 7:04am.

Alternative Solutions

I can manually rename individual run sessions, there's a dropdown menu next to each session title in the sidebar with rename, archive, and delete options. So as a workaround right now, I could rename each run entry to the date after it completes, but that's obviously manual and tedious.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗