Repository navigation
Tool-call emission sticks to bash after heavy Write-Output use; intended read/edit/glob calls emitted as bash Write-Output ... (mimo-v2.6-pro via opencode-go) #57584
Description
Summary
After a phase of ~150 bash calls that use Write-Output "---" as output separators, the model's tool-name selection collapses to bash. Intended read/edit/glob/todowrite calls are emitted as bash calls with command: Write-Output "<intent text>" (e.g. Write-Output "using Read tool now", Write-Output "test read tool").
The model's reasoning explicitly says it will use the Read tool, while the emitted tool call is bash. The calls carry model-generated callIDs (e.g. call_33e9e71edc2e420387ea4ede), and permission=read is never evaluated in opencode.log during the incident — the calls never arrive as read/edit.
The state persists across app restart and session fork (the fork copies the poisoned history). Complex bash commands still work normally — only the tool-name selection collapses to bash + Write-Output.
Evidence
- Reasoning vs emission mismatch (from
parttable of~\.local\share\opencode\opencode.db):- reasoning: "I need to use the Read tool before Edit. Let me read the files properly with the Read tool."
- emitted call:
{"type":"tool","tool":"bash","callID":"call_33e9e71edc2e420387ea4ede","state":{"input":{"command":"Write-Output \"skip\""},...}}
- The model's own probe strings leak intent:
Write-Output "lectura via Read tool",Write-Output "using Read tool now",Write-Output "read tool required",Write-Output "pre-read ok". opencode.logshows onlypermission=bashevaluations during the loop (allowed viaaction.permission=*); nopermission=read|editevaluations between 21:50–22:20Z.- Timeline (2026-10-20, UTC):
- 18:58–19:02Z:
read/edit/grep/todowriteall work fine (edits committed). - 19:02–21:50Z: merge-archaeology phase, heavy use of
Write-Output "---"separators insidebashcommands (~150 calls). - 21:50:21Z: first collapsed call (
Write-Output done) — the turn where the model announced "Now I apply the changes. First I read the files with the Read tool" and emitted twobashcalls instead of tworeadcalls. - 21:50–22:19Z: ~300 degenerate probes (
Write-Output "ok",Write-Output "x",Write-Output "a", ...), one per step, each with reasoning that insists on using Read/Edit. - Persists after restart + session fork: post-restart attempts to call
read/glob/todowriteare again emitted asbash Write-Output "...".
- 18:58–19:02Z:
- NOT reproducible in a parallel session with the same model/provider running at the same time (same machine, same config): that session executed 34
edit, 16read, 8glob, 22grep, 6writewithout issues. Only the tool-name selection is affected in the poisoned session; multi-line PowerShellbashcommands keep working there.
Steps to reproduce
- Long session with many
bashcalls that useWrite-Outputas output separators (~150+). - Attempt to switch to
read/edittool for file work. - Observe: the emitted call is
bashwithcommand: Write-Output "..."instead of the intended tool.
Expected
read/edit calls are emitted with the correct tool name, as they were earlier in the same session.
Actual
All non-bash tool attempts are emitted as bash/Write-Output "<intent text>", indefinitely, across restarts and forks.
Environment
- opencode (Windows 11),
llm.runtime=ai-sdk providerID=opencode-go,modelID=mimo-v2.6-pro- 2026-10-20, sessions
ses_ea5523ebbffe4lNJ86iSPgRb94(incident) /ses_ea48e9746ffevOeLJV4TDNmgez(fork, still reproducible)
Activity
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed report and the timeline.
A couple of things would help us work out whether this comes from OpenCode or from the model:
opencode --versionand how you installed it.ses_ea48e9746ffevOeLJV4TDNmgez), switch to a different model (one not from the mimo family), ask it to read a file, and tell us whether it emits a realreadcall or also falls back tobash Write-Output.So far this looks like the model copying the pattern in its own history. The reasoning says "use Read" while the emitted call is
bash, it only happens once the history holds about 150Write-Outputcalls, it carries over into a fork (which copies that history), and a parallel session with the same model and config works fine. If another model behaves correctly on the same session, the problem is most likely with the model rather than OpenCode.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 when you're done.
I didn't find an exact duplicate. These issues are related, ordered by likelihood:
sbricchi commentedon Oct 21, 2026
opencode-agent commentedon Oct 24, 2026
We haven't heard back, so I'm closing this for now. We still need the output of
opencode --versionand the result of asking a non-mimo model in the forked session (ses_ea48e9746ffevOeLJV4TDNmgez) to read a file. Those would tell us whether this is an OpenCode problem or mimo-v2.6-pro copying theWrite-Outputpattern from its own history.If you can share those details, please comment here or open a new issue that links to this one, and we'll take another look. Related reports you may want to follow: #50634, #57501 and #47759. Thanks again for the detailed write-up.