What happened?

In a long-running session, the assistant read several files and made edits to them. At some point the session sat idle for a while (in one case overnight, in another for over an hour). When work resumed — the user simply asked the assistant to continue — the assistant tried to edit or overwrite a file it had already read earlier in the very same session (in some cases a file it had itself just written earlier in that session).

Instead of proceeding, the tool was rejected with a message stating the file "has not been read in this session" and instructing the assistant to read it first. The assistant then had to re-read files it had demonstrably already read moments earlier (from its own conversational point of view), before it was allowed to edit them.

This was not a one-off. It happened repeatedly, always with the same trigger: the failure appears right after the session resumes from an idle period. Files that were read and edited continuously without an idle gap were never affected.

Concretely, in one session the assistant:

1. Read a file and successfully edited it several times.
2. The user stepped away; the session was idle for an extended period.
3. The user returned and asked it to keep going.
4. The assistant's very next attempt to edit that same file was rejected as "not read in this session."
5. It re-read the identical file (unchanged on disk) and the edit then succeeded.

From the user's perspective, the assistant "forgets" which files it has already read simply because the user took a break, and then gets stuck in a redundant read-then-edit loop while insisting it must read a file it already read.

What did you expect to happen?

The read-before-write safeguard exists for a good reason — to stop the assistant from blindly overwriting a file it has never actually seen. That intent is correct and should stay.

The problem is that this rejection is a false positive. The assistant genuinely did read the file earlier in the same continuous session. Nothing about the file changed on disk. The block is triggered purely by an internal housekeeping step that runs when a session has been idle (cleaning up older parts of the conversation to save space) — not by any real absence of a prior read.

Expected behavior:

• After resuming an idle session, the assistant should still be able to edit or overwrite a file it already read (or wrote) earlier in that same session, without being forced into a redundant re-read — unless the file has actually changed on disk, in which case prompting a re-read is correct and expected.
• Internal context cleanup that happens during idle periods should not, by itself, erase the system's record of which files have already been read. A user pausing their work is not a reason for the assistant to lose track of what it has seen.

The net effect of the current behavior is wasted time and tokens on unnecessary re-reads, and a confusing experience where the assistant contradicts itself ("I already read this" → "you must read this first") after nothing more than a coffee break.

Client information

$ qwen /about
# paste output here

Login information

API config (Anthropic auth).

Anything else we need to know?

• The trigger is consistently an idle gap before resuming the session, not the total session length or the number of files touched.
• It affects both editing an existing file and overwriting a file, including files the assistant itself created earlier in the same session.
• Re-reading the file (which is unchanged) always clears the block immediately, confirming the prior-read requirement is the only thing standing in the way and that the rejection does not reflect any real risk to the file's contents.