Repository navigation
Security: external_directory does not gate PowerShell/bash file writes on Windows #46398
Description
Security: external_directory does not gate PowerShell/bash file writes on Windows
Summary
On Windows, when bash uses PowerShell as the shell, the external_directory
permission is not enforced for file-writing commands. A path outside the
workspace can be written (or read) via a shell command without triggering the
external_directory prompt, even though the docs say it applies to "many bash
commands".
In contrast, the dedicated file tools (read, edit) do respect
external_directory and prompt correctly. This creates an asymmetric security
gap: a config that protects the workspace from external-path writes is fully
bypassed through the shell.
Environment
- opencode version: (tested on current dev / latest release)
- OS: Windows (PowerShell 5.1 as the shell)
permissionconfig reproduces the issue;auto-approveis OFF.
Minimal reproduction
Config:
{
"permission": {
"bash": {
"*": "allow"
},
"external_directory": {
"**": "ask"
}
}
}With this config, run a shell command that writes to a directory outside the
workspace:
Set-Content -Path 'C:\Users\<user>\temp\pwned.txt' -Value 'hi'
# or
'hi' | Out-File -FilePath 'C:\Users\<user>\temp\pwned.txt'Expected
Because the write path is outside the workspace and external_directory is
ask, opencode should prompt for approval (or at minimum apply the same path
guard as the read/edit tools).
Actual
No prompt is shown; the file is written silently.
Why this matters
external_directory is the advertised guard rail for paths outside the
working directory and defaults to ask. If it does not cover shell commands,
then any rule a user adds to protect e.g. ~, secrets, or system paths is
trivially bypassed by running the equivalent operation through PowerShell
(Out-File, Set-Content, Copy-Item, Remove-Item, New-Item, …).
Suggested direction
- Extend path extraction/parsing of
bashcommands so that file paths passed as
arguments (including PowerShell parameters such as-Path/-FilePath) are
checked againstexternal_directory. - Or explicitly document that
external_directoryonly covers the structured
file tools and NOT shell commands, and provide a supported way to guard
path-based shell usage.
Repro details
- Dedicated
readtool on an external path does prompt (works as expected). - Equivalent PowerShell write through
bashdoes not prompt (gap).
Happy to provide more repro steps or a patch if helpful.
Activity
github-actions commentedon Aug 31, 2026
This issue might be a duplicate of existing issues. Please check:
external_directorypermission (same root cause — bash command allowlist doesn't cover all command forms, specifically redirection targets)external_directorydoes not fire for many bash commands that write outside the project (same allowlist gap on Linux)external_directory: "deny" gets bypassed depending on which bash command you use (macOS, same per-command inconsistency)Your report adds valuable detail about the Windows/PowerShell surface (PowerShell parameter names like
-Path/-FilePathnot being parsed), which may be worth calling out as a distinct aspect even if the underlying cause is shared.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report! This was filed against OpenCode v1 (the
permission/bashconfig and the date point to 1.x). v1 now only gets fixes for critical bugs, and thebashtool not enforcingexternal_directorywas already reported there and closed as not planned (#40159, #42979, #44728). So it's unlikely to be fixed in v1. Until then, settingbashto"ask"gets you a prompt for every shell command.We recommend upgrading to v2 (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0). The same gap also exists in v2 and is tracked there. These are ordered from most to least related:external_directoryaskis skipped forshell, with the same PowerShellSet-Contentexample. It has been reproduced on v2.external_directorycheck.git -C).If you think this is critical for v1, or you see something on v2 that #56288 doesn't cover, please reply here and explain.
opencodejr commentedon Oct 29, 2026
Closing this as not planned. It was reported against OpenCode v1, which only gets critical fixes, and the same
bash/external_directorygap in v1 was already closed as not planned (#40159, #42979, #44728). We waited a day in case you could confirm it's critical or also happens on v2, and there was no reply.The same problem in v2, including the PowerShell
Set-Contentcase, is tracked in #56288, and open PR #56390 would fix it. Please follow those for updates. If you see something on v2 that #56288 doesn't cover, open a new issue with youropencode --version. Thanks for the thorough write-up!