edit permission uses relative paths but external_directory uses absolute paths, breaking agent-level path rules

[fluency03]

Description

When configuring agent-level permissions with absolute path patterns, external_directory works correctly but edit silently fails to match because they use different path formats internally.

Agent config (YAML frontmatter):

permission:
  edit:
    "*": ask
    "/tmp/my-tmp-folder/**": allow
  external_directory:
    "/tmp/my-tmp-folder/**": allow

Expected: Both permissions resolve to allow for files under /tmp/my-tmp-folder/.

Actual: external_directory resolves to allow, but edit resolves to ask (prompts the user).

Root cause

In write.ts (line 26) and edit.ts (line 45), the edit permission check passes a relative path:

await ctx.ask({
  permission: "edit",
  patterns: [path.relative(Instance.worktree, filepath)],
  // ...
})

But in external-directory.ts (line 18), the external_directory check passes an absolute path:

const glob = path.join(dir, "*")
await ctx.ask({
  permission: "external_directory",
  patterns: [glob],
  // ...
})

For non-git projects, Instance.worktree is / (as noted in the comment in instance.ts). So:

path.relative("/", "/tmp/my-tmp-folder/file.md")
// -> "tmp/my-tmp-folder/file.md"   (no leading slash)

The configured pattern /tmp/my-tmp-folder/** produces regex ^/tmp/my-tmp-folder/.*$, which does NOT match tmp/my-tmp-folder/... (missing leading /).

The "*": ask catch-all is the last matching rule, so the user gets prompted.

Steps to reproduce

1. Create an agent markdown file with the config shown above
2. Start OpenCode in a non-git directory (so Instance.worktree is /)
3. Have the agent write a file to /tmp/my-tmp-folder/test.md
4. Observe the permission prompt despite the allow rule

Suggested fix

Normalize the path format so edit and external_directory use the same representation when matching against permission rules. Either:

• Use absolute paths consistently in both checks, or
• Document clearly that edit patterns are relative to the worktree and external_directory patterns are absolute

The first option is better UX since users configure both in the same permission block and expect the same path format.

Environment

• OpenCode version: 1.3.0
• OS: macOS (arm64)

---

Issue is discovered by OpenCode :)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• opencode serve uses / as base directory when started from non-root path allowing access to arbitrary locations + permission path mismatches #14445: Describes the same root cause — the edit permission check passes a relative path (e.g. workspace/projects/project6/test.py without a leading /), which fails to match absolute-path rules like /workspace/projects/**. The logs in that issue even show pattern=workspace/projects/project6/test.py matching against ** (deny) instead of the intended absolute-path rule — identical to the behavior reported here.

[ariane-emory]

Using absolute paths seems like the wrong choice here, in my opinion it would likely be better to regain consistency by allowing relative paths in external_directory.

[fluency03]

in my experience, relative paths are bit tricky to manage.

one of my pattern of using OpenCode is running opencode serve in one place and have it running, and run opencode attach to start a client - this is so that I am not starting an OpenCode server everytime which takes more resources on my machine and has a relatively slow startup time.

however, what I have observed is that the "working directory" is based on where opencode serve (/path/A) is started instead of where opencode attach is started (/path/B, /path/C). this has been bugging me for a while.

[ariane-emory]

@fluency03 Typically, I have multiple copies of any given git repository located at different paths and run individual instances of OpenCode in each one simultaneously. If they had to share absolute paths in the permissions in the project-local settings then that would plainly run into problems.

[fluency03]

@ariane-emory I do see the rational of that.

But in my case

• I decided to run opencode serve in one place, have it running, and run opencode attach to start different clients at different places because:
  • I do see a much faster start up time of the UI comparing to starting a server everytime (plain opencode) especially some of the MCP servers can be heavy;
  • (please correct me if I am wrong) and I think single server means single set of MCPs running, whereas multiple server means multiple set of MCPs running -> this can be expensive in CPU and memory usage on my machine;
    • imagine you have 5 servers running, if each server has 3 MCPs enabled, that's already 15 MCP processes running...
  • I am not even running opencode attach for the same projects in different copies. I am running multiple clients for all of my work across Q&A, multiple different projects, etc, in order to gain the fast start up time and low CPU/memory.
    • and specifically, I have lots of use cases where I just need to do some investigation or document review - these tasks are not bound to any specific git repository;
• Regarding share absolute paths in the permissions, i'd like to write some of the intermediate content of aubagents and thinking processes of the agent into files so that I can review them later. And I'd prefer to use /tmp. I think it should be ok to share permissions to /tmp or a specific directly of /tmp. And on top of that, I am only giving /tmp/some-dir in the custom agent config, not on the top level of OpenCode.

and regardless, there is an inconsistency between how path is recognized in external_directory vs. edit which can be confusing and it's not documented.

thanks!

[CarloWood]

The globbing can simply happen against the relative path OR the absolute path as a function of whether or not the glob pattern looks like a relative path or an absolute path itself.

Currently all "edit" patterns look like relative paths, or they would never match anything.
There is no reason not to match patterns (added in the future) that look like absolute paths (aka, the pattern starts with '/' on linux, or 'C://' or whatever on Windows) against the absolute filepath.

On top of that I think we really should use proper globbing. Having a * match anything even ../ is unacceptable.