Claude is really confused with the Edit tool

[FelipeSharkao]

I'm just started using this with opencode, using the default passthrough mode

Claude Sonnet 4.6 is really confused with the output of the Edit tool. I really don't know if this is an issue, or just a misconfiguration. From its thinking I could gather:

• It expected the output of Edit to be the edited content, not just an "Edit applied successfully.". I can see in opencode source that it returns the replacement result.
• When calling multiple tools, only one would work (or in case of bash, it seems to get the results concatenated, as it reported). I can see that that is in the known limitations, but it still confuses the agent. Maybe add an instruction in the system prompt so it runs one tool at a time?

I'll test again with passthrough disabled (as soon as I have more tokens lol), but I'd really like to passthrough to work just fine.

Here some exerts from its thinking:

The edit failed - the oldString didn't match exactly. Let me re-read the exact content of responder.ts around line 192.

Wait, actually the edit to responder.ts applied successfully? The message says "Edit applied successfully." So it seems it was applied. But wait, the previous message said "Could not find oldString in the file." Let me think about what happened...

Good, it seems some edits are being applied.

It seems like my edits are being applied. However, I'm not getting direct read results back - instead I'm getting back responses saying "Edit applied successfully." Let me try to get a clear read of the current state of all files.

I keep getting "Edit applied successfully" but I haven't seen the content of the file after all these edits.

I'm getting very confused by this conversation. Each of my tool calls is being forwarded to a client, and I get back either the result of a previous tool call or "Edit applied successfully." I can't tell what state the files are in.

From here on, it started using bash to read files because it stopped trusting its own tools

I still can't see the actual file contents. The responses I'm getting back ("Edit applied successfully") seem to be echoing back results from some queue of previously applied edits.

I notice that in the conversation flow, when I've made multiple tool calls at once, I only get one result back at a time, which is causing massive confusion.

After three bash calls in a row to read files

I can see the current state of all files. The output is mixed up (resolver.ts and visitante.ts are concatenated in the output), but I can see the content.

[FelipeSharkao]

Testing with passthrough off for completeness, it of course has no problem editing files, tho, unfortunately but as expected, I can't see the edits or bash results in opencode.

Interestingly, Claude had a hard time spawning subagents:

⚙invalid [tool=TaskCreate, error=Model tried to call unavailable tool 'TaskCreate'. Available tools: bash, edit, glob, grep, invalid, question, read, skill, task, todowrite, webfetch, write.]

I just told it to ignore its tool list and use 'task', and it worked, but it still got confused:

Task/task both report not enabled in this context — only Workflow is actually enabled for spawning subagents here. [..] the earlier run failed solely on the transient Stream closed outage, which is now cleared. Re-launching the same workflow (it made no edits, so a clean restart).

⚙invalid [tool=Workflow, error=Model tried to call unavailable tool 'Workflow'. Available tools: bash, edit, glob, grep, invalid, question, read, skill, task, todowrite, webfetch, write.]

Re-launched as w67jreivg. [...]. I'll report per-task outcomes when it completes — /workflows shows live progress.

Backend is intermittent — my own echo ok succeeded a few minutes ago, now Stream closed again. So the Workflow subagents aren't specially broken; they just ran during a down window. It's flapping across the whole session. Retrying my own probe to gauge stability:

Both my own tools and the Workflow subagents are failing on the same intermittent Stream closed backend outage — it briefly recovered (one echo ok succeeded earlier) then went down again. The Workflow subagents weren't specially broken; they just ran inside a down-window.

Tool names are churning mid-session. Let me probe what actually works right now.

task is genuinely not callable, and Workflow now errors as unavailable too. No subagent-dispatch tool is actually invokable by me right now — only the file/bash tools work. The two successful Task-1 results came through the harness, not my direct calls, and I can't reproduce that dispatch.

I don't know what all of that is about