Config `tool_call: false` does not disable tools

[tobwen]

Description

tool_call: false in model config is ignored by the prompt loop. The code unconditionally resolves SessionTools and sends them in the LLM request body, with tool_choice defaulting to "auto". Providers that serve models without tool-call support (e.g. morphllm without --enable-auto-tool-choice) reject the request with a 400 error.

Root cause

In packages/opencode/src/session/prompt.ts, the SessionTools.resolve() call and the toolChoice parameter in handle.process() both ignore model.capabilities.toolcall. Setting tool_call: false in model config correctly sets capabilities.toolcall to false in packages/opencode/src/provider/provider.ts:1216, but the prompt loop never reads that field.

Why this is bad

The user explicitly opts out of tool calls via tool_call: false, expecting a model-safe request with no tools sent. Instead the prompt loop sends a full tools array with tool_choice: "auto", which providers reject if they do not support tool calling at all. There is no workaround at the session or request level -- the config field is effectively a no-op.

Steps to reproduce

1. Configure a model with tool_call: false:

   {
     "provider": {
       "morphllm": {
         "models": {
           "morphllm/Qwen3-30B-A3B": {
             "tool_call": false
           }
         }
       }
     }
   }

2. Start a session with that model and send a message.

3. The prompt loop calls the provider API with "tools": [...] and "tool_choice": "auto", even though tool calls are disabled.

4. Providers that require --enable-auto-tool-choice and --tool-call-parser flags return HTTP 400.

Expected

With tool_call: false, the LLM request body should contain neither tools nor tool_choice keys. The prompt loop should skip SessionTools.resolve() entirely.

OpenCode version

dev (current)

Operating System

Linux

[github-actions]

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

• 在发送请求时检查 capabilities.toolcall，当为 false 时不发送 tools 参数。 #19966: Same bug — tool_call: false is stored in capabilities.toolcall but not checked when resolving and sending tools in the prompt loop, causing providers to receive a tools array even when tool calling is disabled. That issue is now closed; if the fix did not land or regressed, it may be worth referencing it.

[sbadakhc]

Confirming this on opencode 1.17.15 (linuxbrew binary) against NVIDIA's hosted NIM endpoint (integrate.api.nvidia.com/v1, model nvidia/nemotron-3-content-safety). The endpoint rejects any request carrying tools with vLLM's "auto" tool choice requires --enable-auto-tool-choice and --tool-call-parser to be set, and tool_call: false in the model config does not stop opencode from sending them.

Independent confirmation of the root cause described above: grepping the bundled binary shows capabilities.toolcall is computed during config/catalog merge (toolcall:f.tool_call??_?.capabilities.toolcall??!0) but never read anywhere in the request path, so the config field is a no-op for outgoing requests.

Working user-level workaround until this is fixed: define an agent with the legacy tools wildcard map, which does prevent tool definitions from being sent:

{
  "agent": {
    "safety": {
      "mode": "primary",
      "model": "nvidia/nvidia/nemotron-3-content-safety",
      "tools": { "*": false }
    }
  }
}

Verified working end-to-end with opencode run --agent safety -- the request goes out with no tools and the endpoint responds normally.

Note for anyone trying the recommended permission field instead: permission: { "...": "deny" } does not help here. It blocks tool execution but the tool definitions are still included in the request body, so providers that reject tool-bearing requests still fail.

---

• Agent: Claude Code (Claude Fable 5, model id claude-fable-5)
• Date: 2026-07-09
• Method: log analysis, binary inspection of the opencode bundle, live API probes against the affected endpoint
• Scope: user's local opencode config and logs; no access to opencode source checkout
• Confirmation: no (no code changes; comment only)

---

[IngTian]

There's a fix up for this now: #41463.

I hit the same root cause from a different angle — Vertex Gemini image models (gemini-2.5-flash-image) reject every request with Unable to submit request because the model does not support function calling — and filed #41464 before the duplicate bot pointed me here. Same cause you diagnosed: capabilities.toolcall is assigned in provider.ts and never read in the request path.

The patch is a guard in resolveTools (session/llm/request.ts), which is where every send path converges:

if (!input.model.capabilities.toolcall) return {}

Verified by capturing the outgoing provider request from a source build with the stock build agent and no config overrides: a toolcall: false model now sends no tools field at all (was 12 declarations), while a tool-calling model in the same session still sends all 12. Two tests added; I checked the negative one fails without the guard.

Worth noting this is the third report of the same thing — #19966 (closed by the 60-day inactivity bot rather than on merit), this issue, and #41464. @sbadakhc's morphllm/NVIDIA NIM cases should be covered by the same guard, since it drops the tools array before any provider-specific serialization.

Happy to fold #41464 into this issue if maintainers prefer one thread.