external_directory: "deny" gets bypassed depending on which bash command you use (macOS)

Description

Found something inconsistent with external_directory: "deny". Same external path, same config, but whether it gets blocked depends entirely on which command touches it.

Config (project and global, identical):

{
  "permission": {
    "bash": {
      "*": "deny",
      "ls *": "allow",
      "cat *": "allow",
      "head *": "allow",
      "tail *": "allow",
      "grep *": "allow",
      "rg *": "allow",
      "find *": "allow"
    },
    "external_directory": "deny"
  }
}

Running opencode from /Users/<user>/myapp:

• read tool on /etc/hosts → blocked ✓
• cat /etc/hosts → blocked ✓
• head -1 /etc/hosts → just runs, dumps the content, no prompt at all
• ls /etc/hosts → runs
• ls /etc → runs, full directory listing

So cat gets stopped but head and ls walk right past the same deny rule on the same path. That shouldn't be possible — if external_directory is deny, it shouldn't matter which command is asking.

Related: #17497, #16126, #36681 - those are closed as not planned ("ask" case / Windows), this is different: "deny" on macOS, per-command inconsistency.

Plugins

none

OpenCode version

1.18.21

Steps to reproduce

1. Apply the config above in both the project opencode.json and ~/.config/opencode/opencode.jsonc, then clear the cache (rm -rf ~/.cache/opencode) and restart opencode.
2. Start opencode from /Users/<user>/myapp.
3. Ask the agent to run head -1 /etc/hosts → it executes and prints the content, no prompt, no block (BUG).
4. Ask the agent to run ls /etc → it executes and lists the directory (BUG).
5. Ask the agent to run cat /etc/hosts → blocked (correct — proves the config is enforced for some commands).
6. Ask the agent to read /etc/hosts with the read tool → blocked (correct).

Screenshot and/or share link

Operating System

Mac Os Ventura 13.6.6

Terminal

Apple Terminal