permissions: rule matching depends on spelling (shell deny bypass, inert absolute rules) #58775

Activity

1. opencode-agent commented on Oct 24, 2026

   

   opencode-agentBot

   on Oct 24, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the precise report. I reproduced both parts on the latest dev (17b79f4e0c16), running from source, with a script that calls the same shell scanner and Permission.evaluate the tools use. The script is below.

   Path rules: with edit: * deny followed by edit: /config/** allow and the location /config, the edit tool checks agents/test.md (relative to the location). The absolute rule never matches it, so the edit is denied, while the same file written as /config/agents/test.md is allowed. This is the same root cause as #46358, where the Plan agent's absolute plan-directory rule doesn't apply. PR #53365 proposes a fix for read/edit, and #55739 handles ./-prefixed rules.

   Shell rules: with shell: * allow followed by shell: "sh *" deny, only sh -c … is denied. /bin/sh -c …, env sh -c …, command sh -c …, FOO=1 /bin/sh -c … and ./sh -c … are all allowed, because the rule is matched against the literal command text. The permissions docs currently describe this literal wildcard matching on the parsed command, so maintainers will need to decide whether deny rules should also match normalized command spellings. Related v1 reports: #54008 (wrappers), and #14110 and #16075 (env prefixes).

   Reproduction script (repro.ts)

   // Run from an opencode checkout (dev): REPO=/path/to/opencode bun /path/to/repro.ts
   // Uses the real shell scanner + Permission.evaluate that the shell/edit tools use.
   import { Effect } from "effect"
   import path from "node:path"
   const REPO = process.env.REPO ?? "/workspace/repo"
   const { Permission } = await import(`${REPO}/packages/core/src/permission.ts`)
   const { ShellParse } = await import(`${REPO}/packages/core/src/shell/parse.ts`)
   
   // 1. shell: allow *, deny "sh *"
   const shellRules = [
     { action: "shell", resource: "*", effect: "allow" },
     { action: "shell", resource: "sh *", effect: "deny" },
   ]
   const cmds = [
     "sh -c 'printf x > marker'",
     "/bin/sh -c 'printf x > marker'",
     "env sh -c 'printf x > marker'",
     "command sh -c 'printf x > marker'",
     "FOO=1 /bin/sh -c 'printf x > marker'",
     "./sh -c 'printf x > marker'",
   ]
   for (const portable of [true, false]) {
     console.log(`\n== shell (portable scanner: ${portable}) ==`)
     for (const cmd of cmds) {
       const parsed: any = await Effect.runPromise(ShellParse.scan(cmd, "/bin/bash", "/tmp", { portable }) as any)
       const res = parsed.commands.map((c: any) => c.resource)
       const effects = res.map((r: string) => Permission.evaluate("shell", r, shellRules).effect)
       console.log(JSON.stringify(cmd).padEnd(42), "resources:", JSON.stringify(res), "->", effects.join(","))
     }
   }
   
   // 2. edit: deny *, allow /config/** ; location dir /config
   // FileAccess.resolve reports in-location targets as path.relative(location.directory, absolute)
   console.log("\n== edit ==")
   const editRules = [
     { action: "edit", resource: "*", effect: "deny" },
     { action: "edit", resource: "/config/**", effect: "allow" },
   ]
   const location = "/config"
   const absolute = "/config/agents/test.md"
   const resource = path.relative(location, absolute) // what the edit tool asserts
   console.log("target", absolute, "resource", JSON.stringify(resource), "->", Permission.evaluate("edit", resource, editRules).effect)
   console.log("same target as absolute", "->", Permission.evaluate("edit", absolute, editRules).effect)

   Run it: bun repro.ts
2. opencode-agent

   added

   reproduced

   on Oct 24, 2026
3. vazw commented on Oct 24, 2026

   

   vazw

   on Oct 24, 2026

   Author

   More actions

   Thanks — that matches what I see on my side.

   On the path half: agreed it is the same root cause as #46358, and #53365 and #55739 already propose fixes there. I will leave that half to those PRs rather than open a competing one.

   The shell half is the part I would like to fix here. #54008 was closed because v1 only takes critical fixes and it asked for a v2 report — this is that report.

   Before I open a PR: is deny-only normalization acceptable? What I have derives one extra spelling per command (path-qualified /bin/sh, wrapper-stripped env sh / command sh, assignment-stripped FOO=1 /bin/sh) and uses it only to find deny witnesses. It is never passed to the allow/ask evaluation, to prompts, to saved grants or to permission events, so an extra spelling can only tighten a decision. It cannot widen an allow, and it does not change what "Always allow" stores.

   If you would rather normalize at save time, keep the documented literal matching, or handle this differently, say so and I will adjust instead of opening something that gets declined.
4. Project579

   marked bash deny rules don't apply through wrappers (time, env, bash -c) on v2 #62513 as a duplicate of this issue on Nov 7, 2026
5. Project579 commented on Nov 7, 2026

   

   Project579

   on Nov 7, 2026

   More actions

   +1 for the deny-only approach, it's the smallest safe fix. Two more cases from my v2.2.5 repro (#62513) that stripping wrappers alone wouldn't catch, in case they're in scope:

   • Commands that take another command as an argument: bash -c 'rm x', sh -c 'rm x', echo x | xargs rm, find . -name x -exec rm {} \;, plus nohup, timeout 5 and time as prefixes. With "rm *": "deny" all of these delete the file.
   • "Allow always" on a wrapped command saves the wrapper pattern (env *, bash *, find *, timeout *), which then allows any command behind that wrapper. The deny-only change leaves this as is; it might be worth a separate issue.