Repository navigation
bash_write: 72 of 74 calls fail from Qwen3.8-Flash-Next, which uses it as a shell substitute #691
Description
What happens
On opencode 2.1.2 with @cortexkit/aft-opencode (0.58.2 through 0.61.0), Qwen3.8-Flash-Next calls bash_write as if it were the shell. No background task exists, so it invents or reuses a taskId:
| input | result |
|---|---|
{"taskId":"x","input":""} |
background task not found: x |
{"taskId":"x2","input":""} |
background task not found: x2 |
{"taskId":"noop","input":""} |
background task not found: noop |
{"taskId":"none","input":""} |
background task not found: none |
{"taskId":"bash-dummy-nonexistent","input":"..."} |
background task not found |
{"taskId":"bash-159686","input":""} |
background task not found |
Counts from one machine's session store (SQLite, 24 sessions, 2026-10-14 .. 2026-10-21; an error is a tool result whose stored status is error):
| model | tool | calls | errors | rate |
|---|---|---|---|---|
| Qwen3.8-Flash-Next | bash_write |
74 | 72 | 97.3% |
| Qwen3.8-Flash-Next | bash_status |
576 | 101 | 17.5% |
| deepseek-flash | bash_status |
98 | 1 | 1.0% |
| Qwen3.8-27B | bash_status |
39 | 0 | 0.0% |
| deepseek-flash | bash_watch |
465 | 3 | 0.6% |
| deepseek-flash | bash_kill |
54 | 0 | 0.0% |
| Qwen3.8-Flash-Next | bash_watch |
88 | 5 | 5.7% |
Other models respect the contract, so this is one model family's misreading -- not a broken tool. Two distinct id populations show up: obvious placeholders (x, x2, y, z, noop, none, none2, nada, void, dummy, bash-1, bash-x) and genuine-looking bash-<hex> ids that belong to no task in the session (possibly stale after an AFT restart, which the error text already contemplates).
17 of the 72 errors carry an empty input: the model is not even trying to type anything, it is trying to run a command.
The error does not correct the behaviour
The reply is a paragraph about lost records: "No record of this task exists for this session. If this ID came from a bash tool result or completion notice, its record was lost (for example across an AFT restart); otherwise it is not a task ID. Either way, re-run the command instead of polling."
In session ses_ea0364934... (2026-10-21 21:46-21:49, a research subagent) the sequence was:
bash_write {"taskId":"placeholder","input":""}-> errorbash_write {"taskId":"x","input":""}-> error- host shell tool -> the command ran
The model's own reasoning between (1) and (3): "I meant to use the shell tool, but I ended up typing bash_write."
Ask
- On an unknown
taskId, return a one-line redirect instead of the forensic paragraph -- e.g. "no such task: usebashto run a command;bash_writeonly types into an existing PTY/background task". - Optional: leave the PTY companions (
bash_write, andbash_status/bash_killif they can be split) off surfaces for sessions that have started no background task.
Related: #382 (user-level tool-description overrides), #362 (slow tool_call warnings mostly bash plumbing).
Environment
- opencode 2.1.2, Linux (NixOS), single user
@cortexkit/aft-opencode0.58.2, 0.59.0, 0.60.0, 0.61.0 (the window spans those installs)- model: Qwen3.8-Flash-Next (NVFP4 build), thinking enabled,
xhigheffort - the same model also writes complete
<tool_call>blocks inside its thinking channel (a separate, documented model pathology); none of the counts above involve that path
Activity
aft-alfonso commentedon Oct 21, 2026
Thanks for the counts and the session trace, they make the cause clear. We agree the error should point the model back to
bash. The next release replaces the paragraph with one line: there is no running task with that id in this session; to run a command usebash, andbash_writeonly types into a task thatbashstarted.We are not hiding
bash_writeuntil a task exists, because changing the tool list during a session breaks the prompt cache for every model.mason: one-line unknown-task replies that point to bash (issue cortex…