Instance.containsPath() compares mixed canonical/non-canonical paths

[brndnblck]

Description

After #16651, Instance.directory is always the canonical (symlink-resolved) path. But the filepath argument to containsPath() comes from various tool callers (bash.ts, external-directory.ts, file/index.ts) and is not canonicalized. Similarly, Instance.worktree may not be canonical.

This means a symlinked path passed to containsPath() won't match the canonical Instance.directory, causing:

• bash.ts:89,129 — false negatives on the boundary check, triggering unnecessary external_directory permission prompts for paths that are actually inside the project
• external-directory.ts:17 — same false negative, prompting for permission when none is needed
• file/index.ts:503,585 — File.read() and File.tree() incorrectly reject symlinked paths within the project

The existing TODO comments at file/index.ts:501 and :583 acknowledge this as a known limitation ("lexical containment check"). #16651 makes it slightly more pronounced because Instance.directory is now always canonical while inputs remain uncanonicalized.

A fix would be to canonicalize the filepath argument inside containsPath():

containsPath(filepath: string) {
  const resolved = Filesystem.resolve(filepath)
  if (Filesystem.contains(Instance.directory, resolved)) return true
  if (Instance.worktree === "/") return false
  return Filesystem.contains(Instance.worktree, resolved)
}

Steps to reproduce

1. Create a symlink to a project directory: ln -s ~/myproject ~/myproject-link
2. Run opencode from the symlinked path: cd ~/myproject-link && opencode
3. Use a tool that accesses a file via its symlinked path (e.g., bash tool with cwd set to the symlink path, or file read via symlink)
4. Observe unnecessary external_directory permission prompts for paths that are actually inside the project

Operating System

macOS, Linux (anywhere symlinks are common)

[github-actions]

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

• Symlinked project directories break after 8a95be4 (realpath resolution) #16647: Same root cause (symlink path canonicalization after fix: resolve symlinks in Instance cache to prevent duplicate contexts #16651), same author — covers session breakage when launching from a symlinked directory. Issue Instance.containsPath() compares mixed canonical/non-canonical paths #16660 focuses specifically on containsPath() mixing canonical/non-canonical paths, which may be a sub-problem of Symlinked project directories break after 8a95be4 (realpath resolution) #16647 or a follow-up fix.
• Two server instances created when project path contains symlink, causing TUI to freeze on prompt #15482: Two server instances created when project path contains a symlink, causing TUI freeze — overlapping symptom (symlinked working directory causing incorrect behavior).

If #16660 is intentionally a more focused/actionable follow-up to #16647, it may be worth linking them explicitly or closing one in favor of the other.