tools: agents fall back to bash/powershell for read/write because read loses indentation and edit requires exact byte match #54400

Activity

1. opencode-agent commented on Oct 10, 2026

   

   opencode-agentBot

   on Oct 10, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the report! As written it's hard to act on: it says read appears to lose indentation, but it doesn't show an example. Could you (or the human user) briefly describe in your own words what you did, what you expected and what you actually saw, and include:

   • A minimal file that triggers it (or a short snippet), plus its line endings (CRLF, LF or mixed), its encoding and whether it uses tabs or spaces.
   • The exact read tool output for that file, showing the lost indentation, and the exact error text from edit together with the oldString that was sent.
   • The provider and model the agent was using.
   • Whether it still happens with your plugins disabled (enforce-bash-timeout, eval-loop-state, etc.).

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done editing.

   These existing issues may already cover part of this. They're ordered from most to least likely to match:

   • The edit tool intermittently reports "Could not find oldString" for text that is verifiably present in the target file #52067: edit reports "Could not find oldString" for text that is in the file, including indented strings (edit: oldString with leading indentation fails to match ("Could not find oldString") #53036 was closed as a duplicate of it)
   • edit: oldString never matches on files with mixed line endings (read strips \r, edit converts whole oldString to CRLF) #45880: on mixed line-ending files, read strips \r but edit converts oldString to CRLF, so matches never succeed (relevant on Windows)
   • edit tool: failed oldString match returns no context — models abandon the edit instead of retrying #42908: a failed oldString match gives the model no context, so models give up on the edit
   • edit tool silently rewrites line endings; tool description contradicts implementation #53149: edit silently rewrites line endings, and the tool description contradicts the implementation
   • edit: not-found error claims exact whitespace matching, but matching normalizes whitespace #44996: the edit not-found error claims exact whitespace matching, but matching actually normalizes whitespace
2. opencode-agent

   added

   triaging

   on Oct 10, 2026
3. nimao33 commented on Oct 10, 2026

   

   nimao33

   on Oct 10, 2026

   Author

   More actions

   Update from the human user (relayed by the AI agent that filed this on their behalf):

   They notice this especially on big files. Small files tend to work with read/edit, but on large files the read output seems untrustworthy for indentation and edit byte-match failures push the agent to fall back to PowerShell/bash for reads and writes.

   We don't have a minimal file plus exact read output and oldString error yet - will add if we can capture one.

   Session context: provider/model openrouter deepseek/deepseek-v4-flash-0731:free. Plugins were enabled as listed in the issue env.
4. opencode-agent commented on Oct 10, 2026

   

   opencode-agentBot

   on Oct 10, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the update. Knowing it happens mostly on big files, and with deepseek/deepseek-v4-flash-0731:free, helps narrow things down.

   Some background that may explain what you're seeing on large files. In v2.0.26 the read tool:

   • Returns a file in pages once it is over 50 KB, with at most 2,000 lines per call. The model has to call read again with offset to see the rest, so for anything past the first page it is editing text it may not have seen in full.
   • Cuts any single line longer than 2,000 characters and adds a ... (line truncated to 2000 chars) note. If such a line ends up in oldString, it won't match the file.

   read doesn't strip leading whitespace, so lost indentation more likely means the model is miscopying whitespace into oldString. Small free models do this more often. That would make this the same problem as #52067 (indented oldString not found), or #45880 if the file has CRLF or mixed line endings, with #42908 explaining why the agent then gives up on the tool.

   To tell whether this is one of those or a separate read bug, we still need one captured example:

   • The file, or a snippet of it, plus its size, line endings (CRLF, LF or mixed) and whether it uses tabs or spaces.
   • The exact read output where the indentation looks wrong, and the exact edit error with the oldString that was sent.
   • If you can, whether it still happens with your plugins disabled and with a stronger model.

   Please reply here once you have it (or edit the issue and leave a comment saying you've updated it).
5. nimao33 commented on Oct 10, 2026

   

   nimao33

   on Oct 10, 2026

   Author

   More actions

   Correction to my previous comment (relayed by the AI agent that filed this):

   I got the provider/model wrong. Please ignore openrouter/deepseek/deepseek-v4-flash-0731:free - that is just the default in my opencode.json, not what was actually running.

   What the human user is actually seeing this on is Muse Spark 1.3 (provider opencode, model muse-spark-1.3-contributor-free) - the model running this OpenChamber session.

   Sorry for the confusion - I should have asked instead of guessing from config. The especially on big files observation still stands, on Muse Spark 1.3.
6. opencode-agent commented on Oct 10, 2026

   

   opencode-agentBot

   on Oct 10, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the correction. We'll go with Muse Spark 1.3 (opencode/muse-spark-1.3-contributor-free) as the model.

   The rest of my previous comment still applies. On big files, read returns pages of up to 2,000 lines once a file is over 50 KB, and it cuts lines longer than 2,000 characters. Neither of these strips indentation, so the likeliest cause is the model miscopying whitespace into oldString, which is what #52067 and #45880 cover.

   Since you're using OpenChamber, it would also help to know whether the same thing happens in OpenCode's own TUI or CLI (opencode). That would rule out the client.

   We still need one captured example to go further: the file (or a snippet) with its size and line endings, the exact read output where the indentation looks wrong, and the exact edit error with the oldString that was sent. Please comment here once you have it.
7. nimao33 commented on Oct 11, 2026

   

   nimao33

   on Oct 11, 2026

   Author

   More actions

   Reply from the human user (relayed by the AI agent):

   I don't want to share the file I'm seeing this with, so I can't give you the exact snippet / read output / oldString triple.

   But yes - that miscopying-whitespace-in-oldString thing is my problem, and it's really annoying. That's the whole point of this issue:

   • Whether read technically strips indentation or the model miscopies it from read output, from my side the result is the same: I copy what read showed me, edit says it can't find oldString / must byte-match, and I have to retry / fiddle with whitespace.
   • Especially on big files (paged read, truncated long lines) it's even worse, so agents just give up and revert to PowerShell/bash to read and write files.

   So please don't close this as "working as intended / model fault". If edit requires exact byte-match including whitespace/line-endings while read output is easy to miscopy, then the tool design is pushing agents toward shell fallbacks. Better error showing what mismatched, whitespace-tolerant matching, or handling paged/truncated reads would fix the annoyance.

   Happy to test a fix on Muse Spark 1.3, but I won't be sharing the original file.
8. opencode-agent commented on Oct 11, 2026

   

   opencode-agentBot

   on Oct 11, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks. That makes it clear, and the annoyance is real. read itself keeps indentation. The real problem is that when the model copies whitespace slightly wrong into oldString, edit gives it nothing to correct against, so agents give up and fall back to the shell.

   For context, in v2.0.26 edit already matches when oldString and the file differ only by:

   • line endings
   • trailing whitespace on each line
   • curly quotes, dashes and non-breaking spaces

   It does not tolerate different leading indentation. When nothing matches, it only says "Could not find oldString… It must match exactly, including whitespace and indentation." without showing the closest text in the file.

   That is exactly what #42908 asks to change, so I think this is a duplicate of it. Related issues, ordered by likelihood:

   • edit tool: failed oldString match returns no context — models abandon the edit instead of retrying #42908: a failed oldString match returns no context and models abandon the edit; it proposes showing the closest matching region so the model can retry
   • [FEATURE]: Make fuzzy edit feedback stricter to improve SWE-bench reliability #34424: stricter, more useful fuzzy-edit feedback
   • The edit tool intermittently reports "Could not find oldString" for text that is verifiably present in the target file #52067: edit reports "Could not find oldString" for indented text that is in the file
   • edit: not-found error claims exact whitespace matching, but matching normalizes whitespace #44996: the not-found error says matching is exact, but some whitespace is normalized

   The bot will close this issue as a duplicate of #42908 in 1 day unless you reply explaining how your problem is different. Your experience with Muse Spark 1.3 on big, paged files would be a useful data point to add on #42908.
9. opencode-agent

   added

   pending close

   on Oct 11, 2026
10. nimao33 commented on Oct 11, 2026

    

    nimao33

    on Oct 11, 2026

    Author

    More actions

    Agreed from the human user (relayed by the AI agent):

    Thanks for the clear explanation - that matches what I'm seeing. read keeps indentation, the pain is edit failing on slightly-miscopied leading whitespace with no closest-match context, so agents bail to shell. Especially painful on big paged files.

    Happy for you to close this as a duplicate of #42908. I won't be sharing the file, but feel free to carry over the Muse Spark 1.3 + big-files data point to #42908 if useful.
11. opencode-agent commented on Oct 11, 2026

    

    opencode-agentBot

    on Oct 11, 2026 – with OpenCode Agent

    Contributor

    More actions

    Thanks for confirming. This will be closed as a duplicate of #42908.

    I can't post on other issues from here, so please add a short comment on #42908 yourself: edit fails on slightly miscopied leading indentation, it happens especially on big paged files, you're using Muse Spark 1.3 (opencode/muse-spark-1.3-contributor-free) on v2.0.26 on Windows, and agents then fall back to PowerShell/bash. Real-world reports like that help maintainers prioritise it. You don't need to share the file.
12. opencode-agent

    closed this as duplicateon Oct 12, 2026
13. opencode-agent commented on Oct 12, 2026

    

    opencode-agentBot

    on Oct 12, 2026 – with OpenCode Agent

    Contributor

    More actions

    Closing as a duplicate of #42908, as agreed above. The problem here is that edit gives no closest-match context when oldString has slightly miscopied leading indentation, so agents fall back to PowerShell/bash. This is worst on big, paged files. #42908 covers exactly that, so please follow it there, and feel free to add your Muse Spark 1.3 experience. #34424 and #52067 are closely related. Thanks for the report and the follow-ups!