Description

I asked OpenCode to write this bug report below. I didn't read it carefully, so here's my short version:

I have:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "external_directory": "deny"
  }
}

… but OpenCode was able to read on the parent dir, and there are no rules allowing that path in any global config. I added two screenshots.

Bug: external_directory: "deny" is bypassed by the bash tool (macOS)

Summary

With permission.external_directory set to deny, the dedicated file tools
(read, edit, glob, grep) correctly block paths outside the project
worktree, but the bash tool can still read (and presumably write) those same
paths with no prompt and no error. This makes the setting ineffective as a
project-boundary guard rail.

Environment

• opencode: latest, via ACP inside WebStorm (not the standalone CLI)
• OS: macOS 27.0.1
• Shell: /bin/zsh
• auto-approve: off

Config

Project is a nested git repo, so its worktree root is the project root
~/w/parent0/parent1. Config:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "external_directory": "deny"
  }
}

The parent directory ~/w/parent0 is outside this worktree (it is a
separate, outer git repo). ../README.md resolves to ~/w/parent0/README.md,
which is external.

Steps to reproduce

1. Open the project rooted at ~/w/parent0/parent1
   (its own git worktree) and start a session with the config above.
2. Ask the agent to read ../README.md (i.e. ~/w/parent0/README.md).

Expected

All tools should be blocked from touching the external path, per the docs:
"Use external_directory to allow tool calls that touch paths outside the
working directory where OpenCode was started. This applies to any tool that
takes a path as input (for example read, edit, glob, grep, and many
bash commands)."

Actual

• read tool is correctly blocked. Attempting to read
  ~/w/parent0/README.md returns:

  The user has specified a rule which prevents you from using this specific
  tool call. [{"permission":"*","action":"allow","pattern":"*"},
  {"permission":"external_directory","pattern":"*","action":"ask"}, ...
  {"permission":"external_directory","action":"deny","pattern":"*"}, ...]
  

  (the final external_directory -> * -> deny rule fires as intended)

• bash tool is NOT blocked. In the same restricted session, all of the
  following ran without a prompt and returned the external content:

  ls -la ~/w/parent0
  git -C ~/w/parent0 remote -v
  git -C ~/w/parent0 log --oneline -3
  cat ~/w/parent0/README.md   # would read external file

  So the boundary is bypassed simply by using a shell command instead of the
  structured file tools, including via -C/absolute paths that never touch the
  project directory.

Impact

Any rule a user relies on to keep the agent inside the project (secrets, sibling
repos, ~, system paths) is trivially bypassed through bash. The two paths
diverge: read/edit honor external_directory, bash does not.

Related existing issues

• external_directory: "deny" gets bypassed depending on which bash command you use (macOS) #44728 — external_directory: "deny" gets bypassed depending on which bash
  command you use (macOS, same per-command inconsistency)
• Security: external_directory does not gate PowerShell/bash file writes on Windows #46398 — external_directory does not gate PowerShell/bash file writes (Windows)
• external_directory does not fire for many bash commands that write outside the project #40159 — external_directory does not fire for many bash commands that write
  outside the project (Linux)
• Shell redirection bypasses the external_directory permission #42979 — Shell redirection bypasses the external_directory permission

This report confirms the same gap on macOS/zsh and on the ACP surface.

Suggested direction

• Apply the same path guard used by read/edit to paths parsed out of bash
  commands (arguments, redirection targets, and -C/absolute paths), or
• Explicitly document that external_directory does not cover shell commands,
  and provide a supported way to sandbox bash to the worktree.

Plugins

No response

OpenCode version

1.19.0

Steps to reproduce

No response

Screenshot and/or share link

Then, I saw this:

Operating System

macOS 27.0.0

Terminal

No response