Repository navigation
opencode-go/muse-spark-1.3-contributor emits tool calls with empty/garbled parameters when context full #56665
Closed as not planned
Description
Description
Summary
With model: opencode-go/muse-spark-1.3-contributor, tool calls fails as follows once the context reaches a certain size (I noticed it at around 500K):
Invalid arguments for tool "shell":
- command: Missing key
Arguments provided:
{}
Update the arguments and call the tool again.
It behaves properly after compaction.
Environment
- Model:
muse-spark-1.3-contributor, provideropencode-go - Other models tested on the same setup and project do not exhibit this.
Observed behavior
- Empty-parameter calls across tools (
shell,edit,read,subagent), e.g.:
Invalid arguments for tool "shell": - command: Missing key / Arguments provided: {} - Garbled parameters: foreign tokens injected mid-path, truncated JSON.
- Bursty: clusters of failures, then recovery. Long responses disproportionately affected — consistent with interruption landing on the trailing tool-call block (also seen: provider
server_errors around the same time).
Why a new issue (not a duplicate)
- Interrupted tool calls permanently corrupt session history (orphaned tool_use without tool_result) #21326 covers orphaned
tool_useblocks already in history. Here the call itself never forms correctly — there is no valid history to heal. - Empty bash tool arguments {} can still be submitted and interrupt the session #27871 covers only the bash
{}case and is closed. This affects all tools and includes corruption, not just emptiness. - Same-route precedent (Console Go (Meta Muse Spark): MCP tool schemas deeper than 10 levels are rejected, no Meta/Muse sanitizer #50297, Usage Issue #51451) shows this model route already has parameter-handling strictness issues.
Expected behavior
- Validate required params before dispatch: a call with
{}or missing required fields must fail immediately with a schema error naming the field (e.g.bash tool call rejected: missing required 'command'). - Never dispatch a visibly malformed call; treat assembly interruption as retryable, not as a completed call.
- Keep the session recoverable — today the failure loop makes sessions hard to exit.
Evidence available
Full transcript excerpts with the exact invalid payloads, plus the burst/recovery pattern across a long session. Happy to provide logs on request.
Plugins
"@plannotator/opencode@latest"
OpenCode version
2.0.32
Steps to reproduce
Use >500K context then make tool calls!
Opencode Go request IDs
- dea810d6-9844-4a1d-9023-6a7e24ef4f9d
- b6816fc6-d065-4fbc-a9e3-5363632d956a
- 1c99a33c-8f90-47c2-baaf-74d64d825891
- 14d0b12c-f475-452a-b7c3-7d246c1398e3
Activity
opencode-agent commentedon Oct 18, 2026
Thanks for the report, @esafak.
One thing to note first: the error you quoted (
Invalid arguments for tool "shell": - command: Missing key ... Arguments provided: {}) is OpenCode's own check of the arguments before a tool runs. So the{}call was rejected, not executed, and the model got the error back. What we need to find out is whether the model really sends empty or garbled arguments on this route, or whether they get lost while OpenCode assembles the streamed response. For that, could you share:~/.local/share/opencode/log/opencode.loglines (or the equivalent on your OS) covering a burst of failures, including anyserver_error/retry lines around it. Please remove anything sensitive.{}? Does pressing Esc or interrupting stop it? Can the session continue after that, or do you have to start a new one?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.
Related issues, ordered from most to least likely to be the same problem:
{}tool calls on glm-5.3, which turned out to be a stalled provider stream (tracked in Provider stream can disappear while tool call remains permanently "running" with no timeout/reaper #51291)tool_callswithout sending the call[-]`opencode-go/muse-spark-1.3-contributor` emits tool calls with empty/garbled parameters[/-][+]`opencode-go/muse-spark-1.3-contributor` emits tool calls with empty/garbled parameters when context full[/+]opencode-agent commentedon Oct 18, 2026
Thanks for the report and the request IDs. We looked them up: all four are upstream failures from the model provider (two HTTP 500s that also failed on retry, and two streams where the provider reported a failure mid-response). They're the
server_errors you mentioned rather than the empty-argument calls.The
Invalid arguments for tool ... Arguments provided: {}message is OpenCode validating the call before the tool runs, so malformed calls are already rejected rather than executed, and the error goes back to the model. Since this only happens with this one model past roughly 500K context and goes away after compaction, it looks like the model's own long-context behavior rather than something we can fix in OpenCode. Closing this; compacting earlier on this model is the best workaround.opencode-agent commentedon Oct 21, 2026
Closing this as not planned, since we haven't heard back.
The
Invalid arguments ... Arguments provided: {}error you quoted is OpenCode rejecting the call before running it. Without the logs or a session export, we can't tell whethermuse-spark-1.3-contributoris really sending empty or garbled arguments on the Go route, or whether they get lost on OpenCode's side. We also don't know what keeps the session stuck in a loop.If it happens again, please reply here with the
opencode.loglines from a burst of failures (with sensitive data removed), one empty and one garbled call, and whether Esc or interrupting stops the loop. We can reopen it then. #47902 (corrupted tool arguments across calls) is the closest open issue, if you'd rather add your details there.