[BUG] Cowork: resumed session reasons from the conversation's original date, not the correct current `<env>` date — 8 independent occurrences in one day

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When a Cowork conversation is resumed after a long gap (in my case 83 days), the model reasons from the date the conversation originally took place rather than the current date — even though the <env> block correctly reported today's date the entire time.

This is distinct from the known "stale clock" reports. Nothing in the environment was wrong:

• <env> block said Today's date: Wednesday, August 12, 2026 — correct
• TZ=America/New_York date in the sandbox returned Wed Aug 12 2026 — correct
• Every file the earlier session had written was correctly dated for the day it was written — correct

The model still answered the resumed thread's final question in the original session's time frame. Concretely: the user asked whether to lock his machine or restart while a large cloud-storage folder finished syncing. I gave detailed sync-behaviour advice about a transfer that had actually completed 83 days earlier. Nothing in the conversation contradicted itself, so there was no internal signal that anything was stale.

Why this is worth separating from the existing reports: the accumulated conversation context out-weighed a correct environment. ~30 turns of the original day's context are far more salient to the model than one line in a system block. Existing mitigations assume the clock is the thing that's wrong; here the clock was right and lost anyway.

Scale observed: eight independent sessions on a single day (2026-08-12) each ran their full length on a stale date frame. Seven had the more familiar failure (frozen clock corroborating a stale summary). The eighth — this one — had a correct clock throughout. A project-level instruction file was updated mid-day specifically to require a date check at session start; it did not prevent any of the subsequent occurrences, because a resumed session has no trigger to re-run that check mid-thread.

Impact: misdated artifacts written to disk, advice given about work that had long since completed, and in other sessions that day, edits applied to files from a months-old base. Several required manual reversal.

What Should Happen?

On resuming a conversation after a meaningful gap, the model should reason from the current date and should treat any in-flight state referenced by earlier turns (a running sync, a pending reply, an unsent draft, a queued job) as expired until re-verified.

Some possible mitigations, roughly in order of how robust they seem:

1. Inject elapsed time, not just the date. A line such as Last turn in this conversation: 2026-05-21. Elapsed since: 83 days. is much harder to overlook than an absolute date that has to be diffed against context the model has already absorbed. The delta is the signal, not the date.
2. Mark the resume boundary in the transcript, so the model can see where the original session ended and the resumed portion began.
3. Timestamp individual turns, or at least the last turn before the gap.
4. Where a gap exceeds some threshold, consider a system-level nudge to re-verify anything the conversation describes as currently happening.

Prose instructions in a project file are demonstrably not sufficient — see the scale note above.

Error Messages/Logs

Steps to Reproduce

Reproduced incidentally 8 times in one day across independent sessions. A deliberate repro:

1. In Cowork on Windows, start a session that does substantive work involving something time-sensitive and still in progress — e.g. a long file sync, a scheduled job, a pending vendor reply. Let the model write files that reference that state as ongoing.
2. End the session normally.
3. Wait a long interval. Mine was 83 days; the other occurrences that day ranged from roughly 1 to 3 months. A few days is likely enough.
4. Reopen the same conversation and ask a short follow-up that depends on the time-sensitive state — e.g. "is that still downloading, or should I just restart?"
5. Observe: the model answers in the original session's frame and treats the long-finished operation as still running. It does not re-derive the date, because the <env> block agrees with reality and nothing in the thread looks inconsistent.

Contrast case that shows the difference:

1. In a fresh session, ask the same question with no prior context. The model has no stale frame to inherit and reasons from the current date correctly.

Notes:

• Asking the model directly to run a date command at step 4 does correct it — but only if something prompts the check. Nothing in the normal flow does.
• In my case the halt came from the user explicitly stopping the session and ordering a date/state verification pass. Absent that intervention, misdated artifacts would have been written to disk, as they were in several of the other sessions that day.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop app, Cowork mode — latest available as of 2026-08-12 (no claude --version exists on this surface; see Additional Information)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment note: this occurred in Cowork mode in the Claude Desktop app on Windows, not the Claude Code CLI. The "Claude Code Version" and "Terminal/Shell" fields on this form don't map cleanly to that surface — there is no claude --version to run from inside a Cowork session, and no terminal involved. I've set Terminal to "Other" and the version field reflects the desktop app rather than a CLI build. Flagging it so the version string isn't misread.

Related existing issues. These are a different failure mode from this one, but they're the nearest neighbours and may share a root cause in how resumed sessions are assembled:

• #49084 — feature request to expose timestamps as structured data for time-aware reasoning. Currently labelled stale. That request is essentially the fix for this bug; this report is the concrete harm case for it.
• #58023 — stale cache observation (Read serving cached rather than on-disk content). Adjacent: in a resumed session a stale read and a stale frame reinforce each other.
• #76593 — Cowork/Windows Edit-on-mounted-folder data loss. Separate bug, same deployment.

One compounding detail worth recording. In a different session on the same machine that same day, Edit reported success on two files; only one write reached disk. Combined with this bug, a session can be running months behind and silently failing to persist some of its writes — so the artifact that would have revealed the date problem is the one that goes missing. I'm not filing that separately since #76593 covers the write-persistence family; noting the interaction because the two together are considerably worse than either alone.

Mitigation attempted and failed. A project-level instruction file was amended mid-day, after the first occurrence, to mandate a date check at session start. Seven further occurrences followed across independent sessions that same day. Prose-level instructions do not appear to be a viable mitigation for this; it likely needs to be structural.