Activity

1. opencode-agent commented on Oct 6, 2026

   

   opencode-agentBot

   on Oct 6, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. This depends on how Gemma-4-31B itself reads the Code Mode instructions, so it needs a maintainer with access to that model to reproduce; our automated environment can only use a simulated model.

   I did read the v2.0.24 prompt text. The Code Mode instructions start with "Use the execute tool to call the tools listed below. They cannot be called directly…", but nowhere do they say that the regular top-level tools (read, edit, etc.) should still be called directly, outside execute. That gap could explain the behavior you're seeing.

   Two details would help whoever picks this up:

   • Which provider or runtime you use to serve Gemma-4-31B (e.g. OpenRouter, Ollama, llama.cpp, vLLM).
   • Whether it still happens with hashline-opencode-plugin disabled. If that plugin registers its own read/edit tools, they may show up in the Code Mode catalog under the same names as the top-level tools.

   You can reply here with the details, or edit the issue and then leave a comment saying you've updated it.
2. github-actions

   assigned

   kitlangton

   on Oct 6, 2026
3. github-actions commented on Oct 6, 2026

   

   github-actionsBot

   on Oct 6, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   This issue might be a duplicate of existing issues. Please check:

   • #51949: An agent stopped using top-level tools and routed tool calls through Code Mode execute instead.
   • #21034: Gemma 4 26B/31B repeatedly failed or looped when using tools to read files.
4. rekram1-node

   assigned

   rekram1-node

   and unassigned

   kitlangton

   on Oct 6, 2026
5. rekram1-node commented on Oct 7, 2026

   

   rekram1-node

   on Oct 7, 2026

   Collaborator

   More actions

   Will adjust instructions, ran evals with lot of smaller models but didnt try gemma or xiaomi
6. janorga commented on Oct 19, 2026

   

   janorga

   on Oct 19, 2026

   Last edited by janorga

   More actions

   Same root cause with DeepSeek 4.1 Flash 1017 (litellm/deepseek-v4p1-flash) — but a different symptom: denial instead of mis-routing. Controlled repro + validated workaround.

   With DS 4.1 the agent never mis-routes top-level tools into execute — it goes further and denies they exist. Asked to read a file, it searches the Code Mode catalog, hits Unknown tool 'read' on the dangling sandbox references, and concludes "in this environment no read tool exists; everything must go through execute", then asks the user to paste the file contents. The exact same prompt with litellm/glm-5p3-flash calls read directly and works instantly.

   Controlled matrix (opencode run, identical probe prompt: "use the read tool on /tmp/opencode/probe.txt, don't use bash or execute", opencode v2.0.32, Linux):

   Config	Model	Result
   default (shared service)	glm-5p3-flash	✅ calls read directly
   default (shared service)	deepseek-v4p1-flash	❌ "no read tool exists"
   default + clarification in the user message	deepseek-v4p1-flash	❌ still refuses
   temp global config + system-level instructions ("native tools are direct, never via execute")	deepseek-v4p1-flash	✅ calls read directly
   control: temp config without instructions, --standalone	deepseek-v4p1-flash	❌ fails

   Takeaways:

   • (a) The native tool declarations do reach the model — a system-level instruction is enough to unlock correct behavior, so nothing is dropped between OpenCode and the provider (both models served via LiteLLM, @ai-sdk/openai-compatible).
   • (b) User-message corrections don't override the Code Mode prose for this model; system-level instructions do.
   • (c) Shared service vs --standalone is not a factor.
   • The dangling tools.read reference inside the sandbox (looks registered, but fails with Unknown tool 'read') acts as false confirmation for the model's wrong conclusion. Related: execute: tools.shell unavailable inside Code Mode runtime despite being in catalog #39312 (closed as expected behavior).

   Suggested fix — one sentence in the generated Code Mode instructions: "MCP catalog tools cannot be called directly — use execute. Native top-level tools (read, edit, shell, …) are NOT part of this catalog and must be called directly as usual." That sentence alone fixed DS 4.1 Flash for us (rows above). Happy to share the exact instruction file we used if useful for evals.