Repository navigation
Split external_directory permission into read vs write #5395
Description
Activity
This issue might be a duplicate of existing issues. Please check:
- [FEATURE]: more general external_directory permissions #4991: More general external_directory permissions - proposes making external_directory permissions more granular and extensible
- [FEATURE]: allow /tmp or $TMPDIR folder access option #4743: Allow /tmp or $TMPDIR folder access option - requests path-specific permission control for external directories
Feel free to ignore if your use case is different from these.
Yeah we need more granular permissions
It would be nice if instead of just ask/allow/deny we can configure it even on directory bases:
something like:"external_directory_read": { "~/.config/opencode/skills": "allow", "*": "ask" }Reacted by Kamil Chmielewski, Mark Erikson, Connor Adams, Eunjae Lee and S3Schiphol- added 8 commits that reference this issue
on Dec 21, 2025 5 remaining items
I also took a stab at it, so it may have been a waste of my time for this PR. It was a learning experience nonetheless. I leave it to the creators of OpenCode to decide which implementation is better. #5905
Sorry @fpdy don't want to overrule you or anything. Was just playing with the codebase to see if I could do it. Didn't know you were also working on it.
Reacted by aobazkAny updates?
I'm looking forward to this feaure as it's really important for Go developer. In many cases we need AI to read latest code from
~/go/pkg/mod/github.comas Go doesn't install deps in work directory but install in folder inside home directory and in normal case. We need only read permissions.Now I need to click accept manually everytimes.
@jgordijn @fpdy I was interested in this too and after reading the current Permissions docs I believe OpenCode can do what you propose. What do you think?
If i do this;
{ "$schema": "https://opencode.ai/config.json", "permission": { "external_directory": { "~/projects/personal/**": "allow" } } }is there a chance that agent will modify external files?
I am having the following simple problem:
- I want write (edit) permissions in the whole worktree (lets say
/path/workspace/worktree) - I want read permissions in a much larger directory structure (
/path/workspace).
For the latter I have to add:
"external_directory": { "{env:WORKSPACE_ROOT}/**": "allow" }(or give permission ever command and verify if it is reading or writing; giving permission 'always' is the same as adding the above).
However, now it seems impossible to specify that you allow edit in
/path/workspace/worktreebecause the pattern given under"edit"is matched against a relative directory, relative to the worktree!Using
"*"also matches "../../evil/access".
Using"/path/workspace/worktree/*"never matches because that doesn't match literally against any relative path.- I want write (edit) permissions in the whole worktree (lets say
Have this fixed?i meet the same problem,,I want to implement something like Codex, where the model can read files globally—able to read anywhere—but editing, deleting, and creating operations are only allowed within the current directory. Operations outside this directory should require asking for permission first.
@smithyyang I fixed this in my dev...CarloWood:opencode:CW09-globbing branch.
Then use, for example,
"**/*"as edit permissions, which no longer match everything but only match the current repository.Example config: https://github.com/CarloWood/ai-cli-bwrap/blob/master/xdg-home/config/opencode/opencode.json#L180
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Still relevant — reopening the discussion from #34014, which was auto-closed as
stale and flagged as a duplicate of this one.The concrete pain point is the approval prompt itself:
⚠ Permission required
Access files outside the project directory
/home/georg/.local/bin/*"Access" hides the one piece of information that decides how I answer. Reading a
reference file outside the project and writing/deleting to it are not remotely the
same risk, yet I get a single yes/no on a glob. If the prompt said read vs.
write/edit, I could approve reads casually and stay strict on writes — instead
I either click through every read (noisy) or grant "always" and silently open up
writes too (unsafe).So this is really two coupled asks:
- Distinguish read vs. write in the permission itself (
external_directory_read
/external_directory_write, as proposed in the original description) — so config
can allow reads and ask on writes. - Show the operation in the prompt text, even for users who keep a single
external_directoryrule. This is cheap and already helps on its own.
The
external_directorypermission is currently a single key gating read, write,
edit, patch and bash workdir access outside the worktree, which makes the common
"read anywhere, write only in the project" setup (what #5395, #34014 and several
later comments ask for) impossible to express — see also #49941 and #51046 for
adjacent permission-UX issues.Prior work exists and would be a reasonable base: #5841 and #5905.
Happy to help drive this forward if the maintainers indicate which shape they'd
prefer (separate keys vs. amodequalifier) — I'd keepexternal_directoryas a
backwards-compatible shorthand for both.Reacted by João Paulo Fontenele- Distinguish read vs. write in the permission itself (
Currently,
external_directoryis a single permission that controls all file operations (read, write, edit, patch, bash workdir) outside the working directory. This makes it impossible to allow reading external files while blocking writes.Use case
I want the agent to be able to read reference files, configs, or documentation outside the project directory without prompts, but still block (or prompt for) any writes to external locations. Currently I must choose between:
"allow"- permits both reads and writes (too permissive)"ask"- prompts for every read (too noisy)"deny"- blocks all external access (too restrictive)Proposed solution
Split into two permissions:
{ "permission": { "external_directory_read": "allow", "external_directory_write": "ask" } }Or alternatively, add a
modequalifier:{ "permission": { "external_directory": { "read": "allow", "write": "ask" } } }Implementation notes
Looking at the source, this would require:
config/config.tsandagent/agent.tstool/read.ts,tool/write.ts,tool/edit.ts,tool/patch.ts,tool/bash.tsto use the appropriate permission typeexternal_directorycould be kept as a shorthand that sets both read and writeNote: This issue was drafted with Claude Opus 4.5