Long-session time/state drift: assistant produces wrap-up artifacts with stale 'today/tomorrow' phrasing after date-rollover system-reminder

Summary

In long-running Claude Code sessions (multi-hour, sometimes spanning a date rollover), the assistant reliably loses track of the current date/time. After a date has changed. Today's date is now <new-date> system-reminder fires mid-session, the assistant updates the immediate response correctly, but downstream artifacts produced later in the same session (handoff docs, BBBU-style status updates, todo-list transitions, commit messages, external messages) continue to reference the OLD date — using "tomorrow AM" when "tomorrow" has already become "today", or "send tomorrow" for actions the user has already performed.

The user has to repeatedly catch and correct the contradiction. After several rounds of correction in a single session, this becomes a real trust-degrader: the user can no longer rely on any time-reference the assistant produces without manually verifying it.

Reproducible pattern

1. Start a long session (~6+ hours, ideally one that spans midnight in the user's timezone).
2. Mid-session, the harness fires a <system-reminder> updating the current date.
3. The assistant acknowledges the new date in its immediate response.
4. Continue the session for another hour or two.
5. Ask the assistant to produce a wrap-up artifact (handoff doc, status update for an external party, commit message, etc.).
6. Bug: the artifact will reference the OLD date in phrasings like "send tomorrow AM," "scheduled for next week (Wednesday)," "status: pending until X." Even if the user has explicitly told the assistant during the session that the date has changed or that the action has already happened, those facts often fail to propagate into later-produced artifacts.

Specific evidence (this session)

In a single session today the assistant:

• Wrote a handoff doc marking an external action as "HOLD for fresh-eye AM review then send" when the action had already been sent the previous evening (the user had explicitly told the assistant).
• Sent a BlueBubbles status update to a stakeholder describing the same action as "ready to send tomorrow AM after fresh-eye review" — propagating the stale fact into an external message the recipient now believes.
• Said "after 48-hours-then-short-sleep" and referenced "9 PM second-wind" while the local time was actually mid-afternoon (~14:21).
• Had to be corrected by the user four separate times in the same session for time-reference errors.

The user's exact words after one of these: "This lack of time awareness is embarrassing and worth raising as issue in github."

Why this is worth fixing

The class of artifacts where this matters most is also the class of artifacts the user is LEAST likely to verify line-by-line — wrap-up docs, BBBU-style status updates, commit messages, external emails. The assistant is trusted to produce these correctly precisely because the user has run out of cognitive budget by end-of-session. A stale "tomorrow" or "pending" in a status message sent to a stakeholder is a real reputational cost for the user.

The fix is also cheap: every date +%Y-%m-%dT%H:%M:%S%z call is essentially free.

Proposed mitigation (one or more)

(A) Ambient time in system context (preferred)

Inject current_time: <ISO-8601 with timezone> into the system context at every assistant turn, alongside current_date. This makes the time ambient — the model can't drift even passively because the ground truth is in every turn's context. Cost is negligible (~30 chars per turn).

(B) Mandatory time-recheck before producing wrap-up artifacts

Define a category of "stateful artifacts" (anything containing date/time references intended for downstream consumption — handoff docs, commit messages, external messages, status updates). Before producing one, the assistant should run date (or equivalent) and verify all references in the artifact against the result.

(C) Skill-level enforcement

A /wrap or /handoff skill (if/when those exist) could automatically re-stamp date references and flag inconsistencies.

(D) System-reminder propagation tracking

When a date/time/state-changing system-reminder fires, the assistant should treat it as triggering an internal "scan all subsequent artifacts for references that may now be stale." Currently the reminder only updates the immediate response.

Environment

• Claude Code via VSCode native extension
• Session length: ~14+ hours of active back-and-forth at time of report
• Date rollover occurred mid-session via system-reminder
• User on Linux, but the bug appears to be model-side, not platform-side

Severity

Medium. The bug doesn't break functionality, but it actively erodes trust in the assistant's status reports and produces external messages with incorrect facts. In professional contexts (job-search updates, project status, customer communications) this can have real downstream cost.