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
and asked Opencode to validate the format of the .env and appsettings.json files in my project.
Opencode correctly detects that it does not have permission to read the .env file and does not access it. However, for appsettings.json, it reports that it does not have permission but then proceeds to read the file anyway.
Plugins
No response
OpenCode version
1.2.20
Steps to reproduce
No response
Screenshot and/or share link
Operating System
macOS Tahoe 26.3
Terminal
Ghostty
Reacted by hkrutzer, Joakim Repomaa, RisaK, Jose, Caspian Baska, Jasha Joachimsthal, a2cc38, Nicolas, Petromir Petrov, kennyliu and 3 more
I will try this approach later, but I’m not sure it will reassure the security team, since OpenCode explicitly states that it does not have the permission (so it wasn’t a configuration issue) but then proceeds anyway.
Same for me. All permissions are ignored.
And all commands running much longer than before (41 s for curl?)
Also, I don't understand why the context always starting form 70000 input tokens? Any way to debug it? I have almost nothing in config and agents.md.
@avramukk This is not a solution, and it doesn’t appear to be a configuration issue since the permission denial was correctly detected but then ignored ( cf the screenshot I shared )
@Nindaleth The tools block is deprecated but can still be used we are just encouraging use of permissions, when you make use of the tools block the way you are it works, permissions are mostly meant for built in tools and even custom user tools, but for mcps, I am not too sure you can restrict them directly for example restricting only git commands for bash. So having an mcp in a tool block as true just means its enabled, and as false as disabled.
@RisaKirisu Plan mode is generally made to NOT edit files, so please make use of another agent than plan mode and add these permissions. Using the build agent and your config I was able to edit that file.
@OpeOginni Thanks for the follow up testing. However, I'm still not observing the same behavior as you. I'm on 1.2.27 now. I have reduced the config file to isolate out the permission system, and applied the settings on build agent only to test, yet the same problem still occur:
@OpeOginni No. I just tested again after running git init in the test dir, and the permission started working expectedly. So it seems the permission system isn't working as intended when the directory isn't a git repo, but works correctly otherwise.
Yeah noticed that as well so since
It's the same with you I can go ahead with a fix for it, should have one out by Monday or if someone else would be faster
This issue seems to still happen even on v1.15.13 of Opencode Desktop on Windows. Neither the read tool nor any other tool prompt for permission when trying to for example access a directory outside of the Working directory while the config for permission says it needs to ask before doing so.
Hope this gets fixed soon as currently opencode can just extract API keys and more from external directories which it should never be able to do. It can also just access other workspaces from it's current one and possibly expose/break stuff there.
Here's my extensive (redacted) config for easy checking btw:
Activity
github-actions commentedon Mar 6, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from these, please add a comment explaining how it differs.
OpeOginni commentedon Mar 6, 2026
@MonsieurTib Was able to reproduce the issue, a solution would be to use this
I omitted the
"*"permission, because that is already added in opencode by default.Try this and let me know how it works for you
MonsieurTib commentedon Mar 6, 2026
I will try this approach later, but I’m not sure it will reassure the security team, since OpenCode explicitly states that it does not have the permission (so it wasn’t a configuration issue) but then proceeds anyway.
avramukk commentedon Mar 6, 2026
Same for me. All permissions are ignored.

And all commands running much longer than before (41 s for curl?)
Also, I don't understand why the context always starting form 70000 input tokens? Any way to debug it? I have almost nothing in config and agents.md.
OpeOginni commentedon Mar 6, 2026
@avramukk ill check this out too
OpeOginni commentedon Mar 6, 2026
@avramukk I am not able to reproduce the issue you have, using your exact config I always get asked before curl is run as set
avramukk commentedon Mar 6, 2026
hmmm, which version? (my is 1.2.20)
OpeOginni commentedon Mar 6, 2026
1.2.20
avramukk commentedon Mar 6, 2026
@MonsieurTib I found it. The problem is MCP. Try to remove it from the config, and it will ask for permissions again
MonsieurTib commentedon Mar 6, 2026
@avramukk This is not a solution, and it doesn’t appear to be a configuration issue since the permission denial was correctly detected but then ignored ( cf the screenshot I shared )
OpeOginni commentedon Mar 6, 2026
What MCPs are you using that prevents permissions from being enforced?
avramukk commentedon Mar 6, 2026
Sorry, it was a cursor plugin
"@rama_nigg/open-cursor@latest"
20 remaining items
OpeOginni commentedon Mar 19, 2026
@Nindaleth The tools block is deprecated but can still be used we are just encouraging use of permissions, when you make use of the tools block the way you are it works, permissions are mostly meant for built in tools and even custom user tools, but for mcps, I am not too sure you can restrict them directly for example restricting only
gitcommands for bash. So having an mcp in a tool block as true just means its enabled, and as false as disabled.should be the same as
and
should be the same as
OpeOginni commentedon Mar 19, 2026
@jhutchings1 could you please use the
/sharecommand and share the link here, of you doing another testjhutchings1 commentedon Mar 19, 2026
@OpeOginni our share links are all behind a corporate SSO config, so the share wouldn't work, unfortunately.
RisaKirisu commentedon Mar 20, 2026
@OpeOginni Thanks for the follow up testing. However, I'm still not observing the same behavior as you. I'm on 1.2.27 now. I have reduced the config file to isolate out the permission system, and applied the settings on build agent only to test, yet the same problem still occur:
{ "$schema": "https://opencode.ai/config.json", "agent": { "build": { "model": "openrouter/google/gemini-3.1-pro-preview-customtools", "tools": { "lsp": true }, "permission": { "edit": { "*": "deny", ".agents/*": "allow", ".agents/*.md": "allow" }, "lsp": "allow" } } }, "small_model": "openrouter/openai/gpt-oss-120b:exacto" }If I change the permission on edit
*toask, the permission behavior for editing.agents/test.mdin practice also become ask.OpeOginni commentedon Mar 21, 2026
@RisaKirisu do you have a git repo initialised on this project?
RisaKirisu commentedon Mar 22, 2026
@OpeOginni No. I just tested again after running
git initin the test dir, and the permission started working expectedly. So it seems the permission system isn't working as intended when the directory isn't a git repo, but works correctly otherwise.OpeOginni commentedon Mar 22, 2026
Yeah noticed that as well so since
It's the same with you I can go ahead with a fix for it, should have one out by Monday or if someone else would be faster
OpeOginni commentedon Mar 23, 2026
@RisaKirisu made a PR that should fix this issue, hopefully it gets merged in
Chaoskjell44 commentedon Jun 1, 2026
This issue seems to still happen even on v1.15.13 of Opencode Desktop on Windows. Neither the read tool nor any other tool prompt for permission when trying to for example access a directory outside of the Working directory while the config for permission says it needs to ask before doing so.
Hope this gets fixed soon as currently opencode can just extract API keys and more from external directories which it should never be able to do. It can also just access other workspaces from it's current one and possibly expose/break stuff there.
Here's my extensive (redacted) config for easy checking btw:
github-actions commentedon Aug 1, 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.