Bulk timestamp assignment in JSONL export after computer sleep/wake

Bug Report: Bulk Timestamp Assignment in JSONL Export After Computer Sleep/Wake

Summary

When exporting Claude Code sessions to JSONL format, many messages receive the same timestamp instead of their original creation time. This appears to occur when the computer goes to sleep during a session and then wakes up, causing all accumulated messages to be assigned the wake/export timestamp.

Environment

• Claude Code version: 1.0.43
• Platform: macOS (Darwin)
• Session file: ~/.claude/projects/-Users-sebastian-projects-dev-trecker/d35c2c8f-c929-4617-a910-e07a0b768bd8.jsonl

Steps to Reproduce

1. Start a Claude Code session
2. Have a conversation with multiple messages
3. Allow computer to go to sleep/idle
4. Wake computer and continue the session
5. Export or auto-save the session to JSONL format

Expected Behavior

Each message should retain its original timestamp from when it was created, preserving the actual chronology of the conversation.

Actual Behavior

Multiple messages receive identical timestamps, specifically:

• 145 assistant messages have timestamp 2025-07-06T11:41:29.497Z
• 85 user messages have the same timestamp 2025-07-06T11:41:29.497Z
• Only a small subset of messages retain unique, chronologically accurate timestamps

Impact

1. Elapsed time indicators show incorrect values (e.g., showing 2h 16m elapsed when messages were seconds apart)
2. Session timeline visualization becomes misleading
3. Performance analysis of coding sessions becomes impossible
4. Historical accuracy of the conversation is lost

Analysis

The pattern suggests that when the system wakes from sleep, all pending messages are flushed to disk with the current timestamp rather than preserving their original creation times. The conversation order is maintained through parent-child UUID relationships, but temporal information is lost.

Evidence from the session file:

# Count of messages with the problematic timestamp
$ jq -r 'select(.timestamp == "2025-07-06T11:41:29.497Z") | .type' d35c2c8f-c929-4617-a910-e07a0b768bd8.jsonl | sort | uniq -c
     145 assistant
      85 user

Proposed Solution

1. Store message creation timestamps in memory immediately when messages are created
2. Preserve these timestamps during sleep/wake cycles
3. Use the original timestamps when writing to JSONL, not the current time
4. Consider adding a separate "export_timestamp" field if the export time is needed

Workaround

For existing files with this issue:

• Use message position/order rather than timestamps for chronology
• Rely on parent-child relationships to reconstruct conversation flow
• Consider position-based elapsed time indicators instead of timestamp-based ones

Related Information

• Session contained 7 different session IDs due to clearing for context window management
• Parent-child relationships correctly preserve conversation flow despite timestamp issues
• The issue affects specific sessions, suggesting it's related to system state rather than a consistent bug