Security: external_directory does not gate PowerShell/bash file writes on Windows

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)
• permission config reproduces the issue; auto-approve is 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 bash commands so that file paths passed as
  arguments (including PowerShell parameters such as -Path/-FilePath) are
  checked against external_directory.
• Or explicitly document that external_directory only covers the structured
  file tools and NOT shell commands, and provide a supported way to guard
  path-based shell usage.

Repro details

• Dedicated read tool on an external path does prompt (works as expected).
• Equivalent PowerShell write through bash does not prompt (gap).

Happy to provide more repro steps or a patch if helpful.