Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix list_sessions MCP tool should expose startedAt alongside lastActivityAt

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

The mcp__ccd_session_mgmt__list_sessions tool returns lastActivityAt for each session but does not expose startedAt. For long-running multi-day CLI sessions, this makes the session's temporal span invisible — it appears only by its last-activity date.

Root Cause

  1. Multi-day sessions are common. A 7-day continuous CLI session (3,600 events) showed up only by its last-activity date. Without startedAt, its full temporal span was invisible, causing confusion about which session covered which time window.

  2. Forensics and audit. "Which session covered the time window when X happened?" is unanswerable from listing-tool output alone for multi-day sessions.

  3. Cross-session reasoning. When an agent discusses "the prior session," both operator and agent need shared session-temporal-bounds. Currently asymmetric.

Code Example

{
  "sessionId": "...",
  "title": "...",
  "cwd": "...",
  "branch": "...",
  "isArchived": false,
  "isRunning": false,
  "lastActivityAt": "2026-05-07T13:37:27Z"
}

---

{
  "sessionId": "...",
  "title": "...",
  "cwd": "...",
  "branch": "...",
  "isArchived": false,
  "isRunning": false,
  "startedAt": "2026-04-30T08:00:56Z",
  "lastActivityAt": "2026-05-07T13:37:27Z",
  "eventCount": 3600
}
RAW_BUFFERClick to expand / collapse

Summary

The mcp__ccd_session_mgmt__list_sessions tool returns lastActivityAt for each session but does not expose startedAt. For long-running multi-day CLI sessions, this makes the session's temporal span invisible — it appears only by its last-activity date.

Current output

{
  "sessionId": "...",
  "title": "...",
  "cwd": "...",
  "branch": "...",
  "isArchived": false,
  "isRunning": false,
  "lastActivityAt": "2026-05-07T13:37:27Z"
}

Proposed output

{
  "sessionId": "...",
  "title": "...",
  "cwd": "...",
  "branch": "...",
  "isArchived": false,
  "isRunning": false,
  "startedAt": "2026-04-30T08:00:56Z",
  "lastActivityAt": "2026-05-07T13:37:27Z",
  "eventCount": 3600
}

Why this matters

  1. Multi-day sessions are common. A 7-day continuous CLI session (3,600 events) showed up only by its last-activity date. Without startedAt, its full temporal span was invisible, causing confusion about which session covered which time window.

  2. Forensics and audit. "Which session covered the time window when X happened?" is unanswerable from listing-tool output alone for multi-day sessions.

  3. Cross-session reasoning. When an agent discusses "the prior session," both operator and agent need shared session-temporal-bounds. Currently asymmetric.

The data exists

The session JSONL's first event already contains the start timestamp — the tool just doesn't surface it. startedAt = first event's timestamp field. eventCount = line count.

Backwards compatibility

Both fields are purely additive — no breaking change.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#conversation history#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING