Symlink inside the project bypasses external_directory, and the permission prompt shows the wrong path #40160

Activity

1. github-actions

   assigned

   jlongster

   on Aug 2, 2026
2. github-actions commented on Aug 2, 2026

   

   github-actionsBot

   on Aug 2, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of or closely related to existing issues. Please check:

   • [FEATURE]: allow external symlink targets via external_directory consent #30788: This feature request describes the exact same symlink escape scenario and proposes the fix (triggering external_directory for in-project symlinks pointing outside the project). Your bug report documents the current vulnerable behavior that [FEATURE]: allow external symlink targets via external_directory consent #30788 wants addressed — they may be resolved together.

   If you believe this is a distinct report worth tracking separately, please let a maintainer know.
3. iceteaSA commented on Aug 9, 2026

   

   iceteaSA

   on Aug 9, 2026

   More actions

   Confirming this independently, and adding one detail about the second half — the misleading prompt path — because it is worse than cosmetic.

   The containment check is FSUtil.contains, which is path.relative plus a .. test, so it is purely lexical:

   worktree  /tmp/symlink-probe/proj
   link      /tmp/symlink-probe/proj/link -> /tmp/symlink-probe/secret
   
   contains(worktree, "proj/link/creds.txt")   -> true    (lexically inside)
   contains(worktree, "secret/creds.txt")      -> false   (correctly outside)
   

   Same file, two paths, opposite verdicts.

   The part worth adding: the path that reaches the permission matcher is the relativized one, so an absolute deny rule on the real location cannot match it.

   permissionPath(via symlink) -> "link/creds.txt"
   realpath                     -> /tmp/symlink-probe/secret/creds.txt
   

   A rule like /tmp/symlink-probe/secret/**: deny is evaluated against link/creds.txt and does not match. So this is not only a missing external_directory prompt — an explicit deny rule covering the symlink's target is silently inert for access through the link. A user who has denied a sensitive directory still gets the read.

   Verified on dev. permissionPath lives in packages/opencode/src/project/instance-context.ts; FSUtil.contains in packages/core/src/fs-util.ts.

   Worth noting that realpath is not a free fix: resolving on every check costs a syscall per permission evaluation, and resolving only the containment check while leaving the emitted path lexical would fix the prompt-absence half but leave the deny-rule half broken. Both halves want the resolved path, which also changes what users see in prompts for legitimately symlinked project layouts.
4. 0xSemizzz commented on Oct 4, 2026

   

   0xSemizzz

   on Oct 4, 2026

   Author

   More actions

   @iceteaSA Given the permission deny-rule bypass you pointed out, do you think #40160 warrants a CVE/security advisory?
5. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
6. thdxr

   closed this as not plannedon Oct 11, 2026