Repository navigation
Bug Report: invalid internal tool is exposed and can spam repeated calls #21900
Description
Description
Summary
OpenCode Desktop exposes an internal fallback tool named invalid in user-facing error output. In some sessions, one malformed tool call can cascade into many repeated invalid call entries, which floods the UI and makes debugging difficult.
Environment
- OpenCode Desktop:
1.4.3 - Platform: Windows
- Install source: Scoop
Actual behavior
- Error messages may show:
Model tried to call unavailable tool ''. Available tools: invalid, question, bash, read, ...
- The UI may then show many repeated
invalidtool-call entries.
Expected behavior
invalidshould remain internal and never appear in user-facing available tool lists.- A malformed tool call should fail once, or be circuit-broken quickly, instead of repeating dozens of times.
Investigation
This does not appear to come from user config. Local config files did not define any invalid tool.
Evidence from the desktop runtime shows:
- An internal tool is explicitly defined:
...\opencode-cli.exe: InvalidTool = Tool2.define("invalid", ...)
- Normal active tools already exclude it:
activeTools: Object.keys(tools).filter((x) => x !== "invalid")
- But unavailable-tool error messages still print an available tools list that includes
invalid:
Model tried to call unavailable tool '${toolName}'. Available tools: ${availableTools.join(", ")}
Likely issue
The runtime seems to filter invalid out of normal active tools, but not out of the error/reporting path. That leaks an internal tool into user-facing output. When the model emits malformed tool calls, the fallback path may repeatedly rewrite them into invalid, causing UI spam.
Requested fix
- Filter
invalidout of all user-facing available-tool lists, including error messages. - Treat
invalidas strictly internal and do not surface it as a normal tool. - Add a circuit breaker so repeated malformed tool calls do not produce dozens of
invalidentries.
Preferred result after fix
Instead of:
Model tried to call unavailable tool ''. Available tools: invalid, question, bash, read, ...
It should be:
Model tried to call unavailable tool ''. Available tools: question, bash, read, ...
And the session should show at most one or very few failure entries, not a long invalid spam sequence.
Plugins
oh-my-openagent
OpenCode version
1.4.3
Steps to reproduce
- Launch OpenCode Desktop 1.4.3
- Start a session with normal tool access enabled
- Ask the model to perform a relatively complex tool workflow, especially:
- multiple tool calls in one response
- parallel tool usage
- complex argument structures
- Once the model emits a malformed tool call (common symptom: empty tool name '', or invalid tool name / argument shape)
- Watch the UI / tool call log
Screenshot and/or share link
Operating System
Windows 11
Terminal
OpenCode Desktop
Activity
github-actions commentedon Apr 10, 2026
This issue might be a duplicate of existing issues. Please check:
invalidinternal tool appears in theAvailable tools:error message and causes repeatedinvalidtool-call entries in the session log.nabilfreeman commentedon May 12, 2026
I think this is the same issue I'm experiencing. Can't tell if it's Opus 4.7, or a recent update to Opencode, but the issue is definitely more pronounced in recent weeks.
When this happens in a subagent, the agent is permanently disabled.
pjohnston commentedon Jun 6, 2026
Hitting this from a different angle — Anthropic claude-code provider (
opencode-claude-code-plugin), not desktop / not an open-source model, so worth adding as a second repro context.Setup
claude-opus-4-7RemoteTrigger,WebFetch,TaskCreate, and allmcp__claude_ai_*__*connectors are not in the default tool list; the model loads schemas on demand via aToolSearch select:<name>call.Symptom
After a context summarization / compaction, previously-loaded deferred tool schemas drop out of the model's working tool set.
On the next turn the model attempts the call directly (it "remembers" the tool worked earlier), and opencode prints:
The model then recovers (re-fetches the schema, retries), and the user-facing call eventually succeeds. So the error is purely cosmetic — but it's loud and includes the entire available-tools list, which dwarfs the actual response.
Why this matters even when not using open-source models
This is the documented Anthropic pattern for keeping the tool schema cheap. Deferred-tool drops after compaction are expected; the harness recovery is by design. opencode rendering each one as a top-level error is the part that's wrong.
Asks (echoing the original report and adding one)
invalidinternal tool out of user-facing output (per the original report).logLevel: WARNshould hide it.Happy to provide a sanitized session transcript if helpful.
github-actions commentedon Aug 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.