Does the position of an earlier file read in context matter — is denying a later re-read of the same file a mistake?

[jayakumarn]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Copilot Agent Mode

Body

Does the position of an earlier file read in context matter — is denying a later re-read of the same file a mistake?

Hi 👋 I'm using a preToolUse hook on Coding Agent — to cut token use in long agent sessions. I've got the correctness cases covered, and I'm left with one question about context behaviour I can't answer from the outside.

What the hook does

When the agent re-reads a file it has already read, my preToolUse hook denies the read (permissionDecision: "deny") with a reason saying the file is already in context. That avoids re-sending the file to the model and saves tokens.

So the only case my hook denies is: the file is unchanged and still in context.

What I already handle

• File edited → I clear the cache entry, so an edited file is always re-read. I never serve a stale version.
• Context compacted → I clear the cache on compaction, so I never tell the agent “you already have this” after the content has actually been dropped from context.

The case I'm unsure about

Here's a concrete example. The agent reads some file — call it config.py — early on. Many turns of other work go by. Then, for a different purpose than the first read, it reads that same file again. It hasn't changed and hasn't been evicted, so my hook denies it.

My worry: the earlier copy is now sitting far back in context, and models attend less reliably to content deep in a long context ("lost in the middle"). So the re-read might be the model deliberately pulling the file forward for its current task — not a redundant repeat. If so, denying it could quietly degrade the result even though nothing is technically missing.

Questions

1. Does read position matter? When a file was read many turns ago but is still in context, is a fresh re-read treated as redundant, or does re-reading meaningfully help by placing the content near the model's current reasoning? Put plainly: is denying a far-back re-read of unchanged content safe, or is it a mistake?

2. Is a repeat read a deliberate signal? Does the agent tend to re-read a file only when it actually needs the content foregrounded for its current step — in which case a deny works against it?

3. Context position in the hook input. Does the preToolUse JSON expose anything I could use to make this call — current context size, token counts, or how far back a previous read sits? I only see toolName, toolArgs, sessionId, timestamp. If there's a way to tell an earlier read is still near the front vs buried deep, I'd deny only in the “still near the front” case.

4. What the model sees on deny. When preToolUse denies a read, is permissionDecisionReason fed into the agent's context as feedback it reasons over, or is it only shown to the user / logs?

Already checked

The hooks docs and reference. Happy to share the hook script or a small repro. If the honest answer is “don't deny re-reads at all,” that's useful to know too.

Thanks!

[sugamnp]

I wouldn’t treat an unchanged file being “still in context” as enough reason to deny every re-read.

A repeat read can still be useful even when the underlying file has not changed. The agent may be re-reading it because it needs the exact conthe new tool result would place that information back near the current reasoning. So while some repeat reads are probably redundant, denying them globally is not a correctness-preserving optimization.

In other words: “already somewhere in context” is not necessarily equivalent to “currently well-grounded on this content.”

For your specific questions:

1. Does read position matter?

Potentially, yes. GitHub does not document any guarantee that a file read much earlier in the session is just as effectively available to the model as a fresh tool result.

A fresh read gives the model the file content again at the current point in the interaction. Denying the read removes that opportunity to re-ground itself.

I therefore would not consider a far-back re-read safely redundant just because the file is unchanged and has not been compacted.

2. Is a repeat read a deliberate signal?

I would treat it as one.

It does not necessarily mean every repeated read is essential, but the agent has chosen to issue the read as part of its current reasoning. It could be verifying an exact implementation detail, revisiting the file for a different purpose, or simply bringing relevant content back into focus.

Blocking that based only on “this path was read before” can work against the agent’s planning.

A safer optimisation would be something conservative such as suppressing only obvious immediate duplicate reads—for example, the same file/range requested again within a very small number of tool calls—rather than caching it for the lifetime of the context.

Even that would still be a heuristic rather than something GitHub documents as guaranteed safe.

3. Can preToolUse tell how deep the previous read is in context?

Currently, no.

The documented preToolUse payload contains:

sessionId, timestamp, cwd, toolName, and toolArgs.

There is no documented context-token count, remaining-context value, attention position, or indication of where an earlier tool result sits in the model context.

You could maintain your own heuristic based on turns/tool calls since the last read, but it would not tell you the model’s actual effective context position.

4. What does the model see when the read is denied?

For Copilot cloud agent, the hooks reference describes permissionDecisionReason as the reason shown to the agent when the tool is denied.

So the agent should receive the denial feedback and can reason/react to it. However, telling it “this file was already read” is not equivalent to giving it the file contents again. The denial reason may explain why the tool failed, but it does not provide the re-grounding that the requested read would have provided.

So my practical conclusion would be:

I would not deny general re-reads solely because the file is unchanged and was previously read.

Your invalidation on edit and compaction handles stale/missing data well, but there is still a third case: the content exists somewhere in context but the agent deliberately wants it foregrounded again. There currently does not appear to be enough information in preToolUse to distinguish that case reliably.

If token reduction is the goal, I’d restrict deduplication to very recent, clearly identical reads rather than treating every unchanged previously-read file as redundant.

[Mihir-Shrestha]

From what I've seen, I'd be cautious about denying repeat reads. Even if the file hasn't changed, the agent may be re-reading it because it's relevant to its current reasoning, not just because it "forgot" it. Bringing the file back into the current context can improve performance, especially in long sessions.

Unless the API exposes context position or token usage (which I don't believe it currently does), it's hard to know whether a re-read is truly redundant. Personally, I'd only optimize this if you've measured a real benefit and confirmed it doesn't affect the quality of the agent's responses.