anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Why must the read tool be executed before the edit tool #2916

New Issue
Open
opened 2026-02-16 17:37:46 -05:00 by yindo · 26 comments
yindo commented 2026-02-16 17:37:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @mooneal on GitHub (Nov 17, 2025).

Question

I've read the description of the edit tool and found it states: "You must use your Read tool at least once in the conversation before editing."
I wonder, if a file is created by AI and its content is already present in the context, would using the Read tool again unnecessarily increase token costs?

Originally created by @mooneal on GitHub (Nov 17, 2025). ### Question I've read the description of the edit tool and found it states: "You must use your Read tool at least once in the conversation before editing." I wonder, if a file is created by AI and its content is already present in the context, would using the Read tool again unnecessarily increase token costs?
yindo added the help-wantedgood first issue labels 2026-02-16 17:37:46 -05:00
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 17, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #4405: Exact same title and question about read tool requirement before edit tool and token cost concerns

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 17, 2025): This issue might be a duplicate of existing issues. Please check: - #4405: Exact same title and question about read tool requirement before edit tool and token cost concerns Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@veracioux commented on GitHub (Nov 17, 2025):

@mooneal I think you accidentally created the same issue twice (#4405).

@veracioux commented on GitHub (Nov 17, 2025): @mooneal I think you accidentally created the same issue twice (#4405).
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 18, 2025):

@mooneal we should handle that case, currently unhandled should be an easy fix

@rekram1-node commented on GitHub (Nov 18, 2025): @mooneal we should handle that case, currently unhandled should be an easy fix
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@renanliberato commented on GitHub (Nov 19, 2025):

Couldn't reproduce. Are we sure it happens?

Image

Write tool seems to mark the file as read after creating it: https://github.com/sst/opencode/blob/5d25758400e546775f7300dc883b0e039df303e9/packages/opencode/src/tool/write.ts#L75

@renanliberato commented on GitHub (Nov 19, 2025): Couldn't reproduce. Are we sure it happens? <img width="1070" height="400" alt="Image" src="https://github.com/user-attachments/assets/e5da2436-62be-4b70-9010-b5b11ccf3804" /> Write tool seems to mark the file as read after creating it: https://github.com/sst/opencode/blob/5d25758400e546775f7300dc883b0e039df303e9/packages/opencode/src/tool/write.ts#L75
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 20, 2025):

Thanks for jumping in @renanliberato

@mooneal can you provide reproduction steps?

Main thing I can think of is that we store the file read time in memory so If the llm reads a file, I quit, restart, then it tries to edit, it will be forced to read again (annoyingly)

@rekram1-node commented on GitHub (Nov 20, 2025): Thanks for jumping in @renanliberato @mooneal can you provide reproduction steps? Main thing I can think of is that we store the file read time in memory so If the llm reads a file, I quit, restart, then it tries to edit, it will be forced to read again (annoyingly)
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@Hoodgail commented on GitHub (Dec 2, 2025):

Happens for me too, can we just have an option of disabling it? as tokens are being wasted. The error "You must use your Read tool at least once in the conversation before editing." appears when the model is attempting to edit a file again. I simply use Opencode as usual; I don't have a replication step. look at the attached image, the time diff between last read and edited is 0.2 seconds

Image
@Hoodgail commented on GitHub (Dec 2, 2025): Happens for me too, can we just have an option of disabling it? as tokens are being wasted. The error "You must use your Read tool at least once in the conversation before editing." appears when the model is attempting to edit a file again. I simply use Opencode as usual; I don't have a replication step. look at the attached image, the time diff between last read and edited is 0.2 seconds <img width="394" height="75" alt="Image" src="https://github.com/user-attachments/assets/05c4d295-34df-4215-b58c-e88b73635523" />
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 2, 2025):

Yeah we could add some flag to disable that, I think often you'll find it saving tokens since the LLM is forced to re-read and makes it less likely to corrupt the file.

Ofc that's the idea behind it at least

@rekram1-node commented on GitHub (Dec 2, 2025): Yeah we could add some flag to disable that, I think often you'll find it saving tokens since the LLM is forced to re-read and makes it less likely to corrupt the file. Ofc that's the idea behind it at least
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@rodnnnney commented on GitHub (Dec 4, 2025):

took a stab at this.

@rodnnnney commented on GitHub (Dec 4, 2025): took a stab at this.
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@renanliberato commented on GitHub (Dec 5, 2025):

Oh, across sessions, nice @rodnnnney

@renanliberato commented on GitHub (Dec 5, 2025): Oh, across sessions, nice @rodnnnney
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@Hoodgail commented on GitHub (Dec 24, 2025):

Pain

Image

The worst part is when the model writes 700 lines of code but gets discarded because of this issue 😭

@Hoodgail commented on GitHub (Dec 24, 2025): ## Pain <img width="987" height="1260" alt="Image" src="https://github.com/user-attachments/assets/b003d48a-08fd-4e00-b475-9331a73c79fb" /> The worst part is when the model writes 700 lines of code but gets discarded because of this issue 😭
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@Hoodgail commented on GitHub (Dec 24, 2025):

Lol why it get worse?

Image

Context going up really cuz of this while nothing is being done

Image
@Hoodgail commented on GitHub (Dec 24, 2025): ## Lol why it get worse? <img width="769" height="2350" alt="Image" src="https://github.com/user-attachments/assets/099e5f31-79ee-4a0c-ab18-dc044a5e4c64" /> Context going up really cuz of this while nothing is being done <img width="140" height="77" alt="Image" src="https://github.com/user-attachments/assets/4ac35111-e256-447b-b06c-998bdbdbe534" />
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@BlueAlitas commented on GitHub (Dec 25, 2025):

I am running into similar issues +1

@BlueAlitas commented on GitHub (Dec 25, 2025): I am running into similar issues +1
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@RayQasey commented on GitHub (Dec 26, 2025):

+1

@RayQasey commented on GitHub (Dec 26, 2025): +1
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@luojiyin1987 commented on GitHub (Jan 1, 2026):

This issue has been addressed in PR #6581 which adds the flag.

The PR allows users to disable the FileTime verification check to:

  • Avoid unnecessary re-reads when file context is already available
  • Eliminate token waste
  • Work around time precision issues causing false positives

Users can set the flag with:

OPENCODE_DISABLE_FILETIME_CHECK=true bun dev

See the PR for details: https://github.com/sst/opencode/pull/6581

@luojiyin1987 commented on GitHub (Jan 1, 2026): This issue has been addressed in PR #6581 which adds the flag. The PR allows users to disable the FileTime verification check to: - Avoid unnecessary re-reads when file context is already available - Eliminate token waste - Work around time precision issues causing false positives Users can set the flag with: ```bash OPENCODE_DISABLE_FILETIME_CHECK=true bun dev ``` **See the PR for details:** https://github.com/sst/opencode/pull/6581
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@luojiyin1987 commented on GitHub (Jan 1, 2026):

PR #6581 has been created to fix this issue.

The PR adds OPENCODE_DISABLE_FILETIME_CHECK flag to allow skipping FileTime verification.

Users can set: OPENCODE_DISABLE_FILETIME_CHECK=true bun dev

PR: https://github.com/sst/opencode/pull/6581

@luojiyin1987 commented on GitHub (Jan 1, 2026): PR #6581 has been created to fix this issue. The PR adds OPENCODE_DISABLE_FILETIME_CHECK flag to allow skipping FileTime verification. Users can set: OPENCODE_DISABLE_FILETIME_CHECK=true bun dev PR: https://github.com/sst/opencode/pull/6581
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@maurits150 commented on GitHub (Jan 1, 2026):

I'd prefer someone who can reproduce this investigates the root cause. Disabling the check entirely is a bandaid, and every extra flag is more code to maintain. Flags should be useful features, not workarounds for bugs?

@maurits150 commented on GitHub (Jan 1, 2026): I'd prefer someone who can reproduce this investigates the root cause. Disabling the check entirely is a bandaid, and every extra flag is more code to maintain. Flags should be useful features, not workarounds for bugs?
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@maurits150 commented on GitHub (Jan 1, 2026):

Are there any external tools / IDE's running that could be auto formatting the files?

'Time precision' is weird because modern filesystems shouldn't have that issue.

OpenCode should fetch the time from the OS after write, and again fetch from the OS before read. So no matter how the clock moves, that is a constant from the filesystem being fetched.

Edit: but looking at the code, OpenCode generates its own timestamp with new Date() instead of fetching from the OS. But this still happens after a write has happened so it should not be an issue.

@maurits150 commented on GitHub (Jan 1, 2026): Are there any external tools / IDE's running that could be auto formatting the files? 'Time precision' is weird because modern filesystems shouldn't have that issue. OpenCode should fetch the time _from the OS_ after write, and again _fetch from the OS_ before read. So no matter how the clock moves, that is a constant from the filesystem being fetched. Edit: but looking at the code, OpenCode generates its own timestamp with new Date() instead of fetching from the OS. But this still happens after a write has happened so it should not be an issue.
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@rodnnnney commented on GitHub (Jan 1, 2026):

If you checkout packages/opencode/src/file/time.ts you can see that the time stamps are only stored in memory and don't persist on the host's computer. That is why you are forced to re read because the in memory reads are lost across sessions. I provided a flow to test in my pr https://github.com/sst/opencode/pull/5045

@rodnnnney commented on GitHub (Jan 1, 2026): If you checkout `packages/opencode/src/file/time.ts` you can see that the time stamps are only stored in memory and don't persist on the host's computer. That is why you are forced to re read because the in memory reads are lost across sessions. I provided a flow to test in my pr https://github.com/sst/opencode/pull/5045
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@rodnnnney commented on GitHub (Jan 1, 2026):

@luojiyin1987 hmm I generally think that files should be read before an agent modifies it. My pr is addressing something different where it is avoiding re reads that only occur because the reads do not persist across sessions (ie, crashes or exits).

@rodnnnney commented on GitHub (Jan 1, 2026): @luojiyin1987 hmm I generally think that files should be read before an agent modifies it. My pr is addressing something different where it is avoiding re reads that only occur because the reads do not persist across sessions (ie, crashes or exits).
yindo commented 2026-02-16 17:37:47 -05:00
Author
Owner
Copy Link
Copy Source

@repairman29 commented on GitHub (Jan 9, 2026):

Hi! I'm interested in helping with this issue.

I have experience with index (repairman29/ai-gm-service) and think I can contribute here. Would love to discuss the approach and see if we can make this happen.

(Connected via Echeo - a platform for matching developers with open source bounties)

@repairman29 commented on GitHub (Jan 9, 2026): Hi! I'm interested in helping with this issue. I have experience with index (repairman29/ai-gm-service) and think I can contribute here. Would love to discuss the approach and see if we can make this happen. *(Connected via [Echeo](https://echeo.io) - a platform for matching developers with open source bounties)*
yindo commented 2026-02-16 17:37:48 -05:00
Author
Owner
Copy Link
Copy Source

@Hoodgail commented on GitHub (Jan 9, 2026):

Hi! I'm interested in helping with this issue.

I have experience with index (repairman29/ai-gm-service) and think I can contribute here. Would love to discuss the approach and see if we can make this happen.

(Connected via Echeo - a platform for matching developers with open source bounties)

L bot

@Hoodgail commented on GitHub (Jan 9, 2026): > Hi! I'm interested in helping with this issue. > > I have experience with index (repairman29/ai-gm-service) and think I can contribute here. Would love to discuss the approach and see if we can make this happen. > > _(Connected via [Echeo](https://echeo.io) - a platform for matching developers with open source bounties)_ L bot
yindo commented 2026-02-16 17:37:48 -05:00
Author
Owner
Copy Link
Copy Source

@BlueAlitas commented on GitHub (Jan 11, 2026):

@maurits150 In an ideal world, we would have a perfect root cause solution, but I understand your concerns about avoiding "band-aid" flags. But as someone who frequently encounters this, I can attest that the current situation is a major productivity killer rather than merely a minor annoyance.

It's not just a waste of tokens (and then having to reread the file) when the model produces more than 700 lines of code and the entire output is discarded due to a failed check; it's a waste of time and context. Many of us are witnessing this occur within active sessions, despite @rodnnnney's PR addressing the session persistence issue (as @Hoodgail noted with the 0.2s time difference).

While we wait for a perfect solution, a "good enough" solution is far preferable to none at all. With the help of @luojiyin1987's PR, we can choose to use the tool consistently once more. We truly need this relief right now, but once the underlying filesystem/timestamp logic is flawless, we can always deprecate the flag.

Strongly in favor of merging #6581 so we can stop losing work.

@BlueAlitas commented on GitHub (Jan 11, 2026): @maurits150 In an ideal world, we would have a perfect root cause solution, but I understand your concerns about avoiding "band-aid" flags. But as someone who frequently encounters this, I can attest that the current situation is a major productivity killer rather than merely a minor annoyance. It's not just a waste of tokens (and then having to reread the file) when the model produces more than 700 lines of code and the entire output is discarded due to a failed check; it's a waste of time and context. Many of us are witnessing this occur *within* active sessions, despite @rodnnnney's PR addressing the session persistence issue (as @Hoodgail noted with the 0.2s time difference). While we wait for a perfect solution, a "good enough" solution is far preferable to none at all. With the help of @luojiyin1987's PR, we can choose to use the tool consistently once more. We truly need this relief right now, but once the underlying filesystem/timestamp logic is flawless, we can always deprecate the flag. Strongly in favor of merging #6581 so we can stop losing work.
yindo commented 2026-02-16 17:37:48 -05:00
Author
Owner
Copy Link
Copy Source

@DavMelchi commented on GitHub (Jan 16, 2026):

+1

@DavMelchi commented on GitHub (Jan 16, 2026): +1
yindo commented 2026-02-16 17:37:48 -05:00
Author
Owner
Copy Link
Copy Source

@Hoodgail commented on GitHub (Jan 16, 2026):

+2

@Hoodgail commented on GitHub (Jan 16, 2026): +2
yindo commented 2026-02-16 17:37:48 -05:00
Author
Owner
Copy Link
Copy Source

@RayQasey commented on GitHub (Jan 19, 2026):

+1

@RayQasey commented on GitHub (Jan 19, 2026): +1
yindo commented 2026-02-16 17:37:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 21, 2026):

merged pr that adds the env var OPENCODE_DISABLE_FILETIME_CHECK

@rekram1-node commented on GitHub (Jan 21, 2026): merged pr that adds the env var `OPENCODE_DISABLE_FILETIME_CHECK`
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label good first issue help-wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2916
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?