Repository navigation
[FEATURE]: SDK-level permission overrides for tools #5965
Description
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
I want to programmatically constrain tool permissions per prompt/session when using the OpenCode SDK, without relying on an on-disk opencode.json.
Use case: In an SDK-driven pipeline, I need to allow only read/edit tools, or allow bash but restrict it to a small allowlist like rg * and sed *. Today, the SDK lets me toggle tools on/off, but command-level allowlists appear to only be read from server config (opencode.json / agent config). This makes it hard to enforce least privilege in transient or multi-tenant workflows where I can’t depend on a host file.
Requested behavior:
- Allow passing a
permissionobject via SDK when creating a session or sending a prompt (e.g.,session.createorsession.prompt). - Support the same schema used in opencode.json, including command allowlists for bash:
{ "permission": { "bash": { "*": "deny", "rg *": "allow", "sed *": "allow" } } } - Ideally allow per-agent overrides in the SDK call (e.g.,
agent: "build"with a permission override for that run).
Why:
- Prevents runaway tool usage when running agents programmatically.
- Enables safe, scoped automation without requiring a persistent config file on the server host.
- Mirrors the existing config-driven permission model, but makes it available programmatically.
Disclaimer: This feature request was drafted with the help of AI.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Dec 22, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
rekram1-node commentedon Dec 22, 2025
Yes totally
rekram1-node commentedon Dec 22, 2025
Dax is shipping some permissions work soon and once that goes through we should add this to SDK.
He is also working on revamping SDK next
ramarivera commentedon Dec 22, 2025
@rekram1-node I would be more than interested in helping out if you would take contributions for this :D any kind of estimates for the permissions work + revamping?
rekram1-node commentedon Dec 22, 2025
The permissions work is this week for sure (or so ive been told, prolly next day or so), idk about the sdk stuff but I guess let's see how stuff looks once his permission stuff lands and I think a contribution for permissions in sdk like this would be accepted.
I think we'd attach it to message state in some way
gempir commentedon Dec 22, 2025
Sorry for going slightly off-topic. But do primary agents need as many permissions as their subagents? Because when I turned off a bunch of permissions from the primary agent, suddendly the primary agent was not away anymore that he even had any subagents.
rekram1-node commentedon Dec 22, 2025
Not sure what u mean by this?
gempir commentedon Dec 22, 2025
Sorry typo. Aware*
The primary agent didn't know anything about subagents. When giving it back permissions, it knew again.
rekram1-node commentedon Dec 22, 2025
hm i'd need to see waht ur config is to help
gempir commentedon Dec 23, 2025
@rekram1-node Here I made a reproducer. https://gist.github.com/gempir/44de37cf64c42e35fe85a2adab4fdbdd
the broken config, will not respond what subagents it has available.
The second config instantly says developer and question.
The config diff:
ashish16052 commentedon Jul 9, 2026
+1 to this use case, especially for transient/multi-tenant automation.
For SDK-driven backends, I think permissions need to be treated as runtime/session input rather than only host-level config. Otherwise the app has to mutate or generate on-disk config just to run one constrained task, which is awkward for least-privilege workflows.
The model I’d like to see is:
That would make it much easier to safely embed OpenCode in backend pipelines without depending on mutable host files.