You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Global default tools configuration for agents #2888
• If defaultTools not set: Current behavior (all tools enabled by default) -
non-breaking
• If defaultTools is set: Only these tools are available by default, agents can
add more via their tools config
• Users can set "defaultTools": [] (empty array): Zero tools by default, opt-in
per agent
This allows clean agent contexts without repetitive configuration across all
agents.
@calvinalkan I think we have these settings in a couple places in the docs, thx for pointing out issue with the generic wildcard false that should be working so I guess there is a bug there
In general I think the question of what tools are actually available/unavailable in a given context is a bit opaque. Perhaps if #2666 gets addressed that would help as one could then at least see what information the models are being fed.
Even from what is in the docs, it's hard to discern the rules. E.g. in docs/agents#tools, we have:
If no tools are specified, all tools are enabled by default.
OK, but what if some tools are specified? Are all other tools disabled in that case? That seems like the obvious inference, and I guess it would be sensible — but it's not explicit anywhere, and I haven't been able to establish the answer to this just by trying things out (maybe a skill issue on my part — again, #2666 would help here).
Okay, I tested this more deeply, and I can confirm it behaves as follows:
"*": false disables all tools globally, but the built-in plan and build agents still
have some tools enabled by default in the source code (they spread defaultTools but
start with an empty object, not hardcoded tools).
Another possible way to provide visibility of this would be to explicitly unpack the information in the API server, so that e.g. on the /agent endpoint, instead of (say):
right now we have a notion of permissions and one for tools, as part of the opentui migration these concepts will be merged and make these spreads and other behaviors both more intuitive and easier to work with (just fyi)
right now we have a notion of permissions and one for tools, as part of the opentui migration these concepts will be merged and make these spreads and other behaviors both more intuitive and easier to work with (just fyi)
IMO, current way is good and flexible, it just needs to be in the docs what the expected bevahiour is.
Activity
rekram1-node commentedon Oct 1, 2025
@calvinalkan there is a tools object at both the agent level and the root of your config.
This means you can disable x or more tools for all agents by default and then enable per agent per tool.
Or you can enable for all agents and then disable per agent
rekram1-node commentedon Oct 1, 2025
I think that should allow you to accomplish what you are looking for here right?
gimbo commentedon Oct 1, 2025
@rekram1-node So e.g. this should work to disable all tools by default, including ones provided by MCP servers or new features added over time...?
calvinalkan commentedon Oct 1, 2025
Oh, i'll check out the source to see how it works. I think it should be what I need.
I think this is missing in the config docs? Or am I blind?
calvinalkan commentedon Oct 1, 2025
This works for me:
{ "$schema": "https://opencode.ai/config.json", "model": "claude-sonnet-4-20250514", "tools": { "bash": false, "edit": false, "glob": false, "grep": false, "linear_*": false, "list": false, "lsp-diagnostics": false, "lsp-hover": false, "multiedit": false, "patch": false, "read": false, "task": false, "todoread": false, "todowrite": false, "webfetch": false, "write": false }, "mcp": { "linear": { "type": "local", "command": ["pnpm", "exec", "mcp-remote", "https://mcp.linear.app/sse"], "enabled": true } } }Sadly, just doing
does not work. Looks like the wildcard is not resolved in agent.ts
rekram1-node commentedon Oct 1, 2025
@calvinalkan I think we have these settings in a couple places in the docs, thx for pointing out issue with the generic wildcard false that should be working so I guess there is a bug there
rekram1-node commentedon Oct 1, 2025
aside from that wildcard not working does this address your issue properly?
gimbo commentedon Oct 1, 2025
That's odd, because it does seem to work for me.
E.g. if I have that, and then add another primary agent with no tools specified:
... then it doesn't seem to be able to use
webfetchorbashwhen I try.This is opencode v0.13.7, hitting
amazon-bedrock/anthropic.claude-3-7-sonnet-20250219-v1:0.gimbo commentedon Oct 1, 2025
In general I think the question of what tools are actually available/unavailable in a given context is a bit opaque. Perhaps if #2666 gets addressed that would help as one could then at least see what information the models are being fed.
Even from what is in the docs, it's hard to discern the rules. E.g. in
docs/agents#tools, we have:OK, but what if some tools are specified? Are all other tools disabled in that case? That seems like the obvious inference, and I guess it would be sensible — but it's not explicit anywhere, and I haven't been able to establish the answer to this just by trying things out (maybe a skill issue on my part — again, #2666 would help here).
calvinalkan commentedon Oct 1, 2025
Okay, I tested this more deeply, and I can confirm it behaves as follows:
"*": falsedisables all tools globally, but the built-in plan and build agents stillhave some tools enabled by default in the source code (they spread defaultTools but
start with an empty object, not hardcoded tools).
My config:
{ "tools": { "*": false }, "agent": { "plan": { "tools": { "linear_*": true } } } }This disables everything NOT explicitly enabled in any agent, then gives plan agent access to
Linear MCP.
So the wildcard works.
gimbo commentedon Oct 1, 2025
Another possible way to provide visibility of this would be to explicitly unpack the information in the API server, so that e.g. on the
/agentendpoint, instead of (say):(which is what's there now, just combining the config from the top level with the per-agent config)
... we could have (e.g.):
... if that makes sense?
rekram1-node commentedon Oct 1, 2025
right now we have a notion of permissions and one for tools, as part of the opentui migration these concepts will be merged and make these spreads and other behaviors both more intuitive and easier to work with (just fyi)
calvinalkan commentedon Oct 1, 2025
IMO, current way is good and flexible, it just needs to be in the docs what the expected bevahiour is.