Chat file links fail with Not allowed to open path outside $HOME

[01dx]

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release.
• This is one bug, not several bundled together.

Closest existing issue

none found. #112 is about adding an in-app file viewer for the Files tray, not about chat markdown/image links being rejected by the opener allowlist.

What's broken

Clicking a local markdown or image path in chat shows Not allowed to open path <absolute path> whenever the file is outside the current macOS home directory, even when that path is the attached project folder and the file exists and is readable.

Steps to reproduce

1. Launch Berd 0.6.2 on macOS.
2. Open or create a project whose working directory is outside $HOME. The path that failed here was an attached project folder under /Users/Shared/....
3. Confirm the folder is attached as the session cwd (berdctl folder list reported that project path as cwd).
4. In that chat, have the agent emit a normal markdown file or image link to a real file inside the attached folder, for example a [label](/Users/Shared/.../file.png) or ![alt](/Users/Shared/.../file.png) link.
5. Click the link in the transcript.

Model/provider does not appear to matter. Reproduced from a Goose chat after the agent had already generated and linked the file. The same toast also appeared for markdown links such as a .md file in the same attached project.

What you expected to happen

Because the file exists, is readable, and sits inside the attached project / session cwd, the click should open it (Finder/Preview or the in-app artifact viewer). Attached project folders should be treated as allowed local paths.

What actually happened

Berd showed a toast:

Not allowed to open path /Users/Shared/.../<file>.png

The file was not opened. open from the shell opened the same file immediately, so this is not a macOS permissions or missing-file problem.

The renderer log records the same failure as an unhandled rejection:

errorName=Error message="Not allowed to open path /Users/Shared/.../ROLE_MAP.md"

How often does it happen?

Every time — reliably reproducible

Berd version

0.6.2

Operating system

macOS (Apple Silicon)

Model and provider

n/a for the click itself. Observed in a Goose chat; the same toast happens as soon as the local path is clicked.

Relevant log output

[2026-08-21][01:39:21][berd_lib::services::diagnostic_log][ERROR] [diagnostic] category=renderer event=unhandled_rejection app_version=0.6.2 platform=macos errorName=Error message="Not allowed to open path /Users/Shared/PROJECTS_shared/LALA/.agents/skills/lala-keyframe-pipeline/references/ROLE_MAP.md" stack="" windowKind=main

/usr/bin/open on the same machine opens the same path successfully.

Screenshots, recordings, or other context

Chat link clicks go through useArtifactLinkHandler -> openResolvedPath -> @tauri-apps/plugin-opener openPath() (src/features/chat/hooks/useArtifactLinkHandler.ts, src/features/chat/hooks/ArtifactPolicyContext.tsx). The toast text is the plugin error Not allowed to open path .

src-tauri/capabilities/default.json on v0.6.2 allows $HOME/**, $TEMP/**, /Volumes/**, /mnt/**, /workspace/**, /workspaces/**, /opt/**, /srv/**, and *:/**. That does not include /Users/Shared/** or other attached project roots outside $HOME.

The shipped 0.6.2 binary also contains a narrower nearby allowlist of $HOME/.goose/**, /Volumes/**, /workspace/**, /workspaces/**, and $DOWNLOAD. Either way, an attached project under /Users/Shared is rejected.

This is not Full Disk Access / sandbox denial: the file is readable, and /usr/bin/open works. The session already has the folder attached as cwd.

Related but separate: the same /Users/Shared/... project images also fail inline preview with asset protocol not configured to allow the path, because tauri.conf.json assetProtocol.scope is $HOME/**/*, $TEMP/**/*, and Berd app-data media caches. I am not bundling that here.

Workaround that works today: open the path from a terminal, or copy/symlink the file into ~/Downloads / $HOME.

[AnobleSCM]

I reproduced this on Berd 0.6.2 and traced three related failure paths.

Root cause:

1. Chat links such as /path/to/SKILL.md:7 are passed to the filesystem literally, so Berd searches for a file named SKILL.md:7.
2. Line-free links to dot-directories or attached roots outside the opener allowlist are passed to openPath, which rejects them before the operating system sees them.
3. Inline local Markdown images use the asset protocol, whose static scope does not cover every attached project root.

I built and verified a local patch against current origin/main with these behaviors:

• Parse terminal :line and :line:column suffixes for absolute, relative, Windows, and file: paths.
• Check the literal colon-containing filename first, so a real POSIX filename still wins.
• Open Markdown inside Berd and reveal other local references in Finder/Explorer through revealItemInDir, rather than widening openPath permissions.
• Read inline images through the existing bounded image command, preserving MIME validation, the 20 MB limit, and session-working-directory containment.
• Make no Tauri capability or allowlist changes.

Verification completed on the final patch:

• 575 test files passed.
• 6,790 tests passed; 1 skipped.
• Formatting, lint, TypeScript, design-system checks, and all Rust cargo check variants passed.
• Independent behavior and standards reviews reported no findings.

The patch touches the artifact-link policy, link click handler, Markdown image renderer, and their tests. I cannot open an upstream PR because this repository does not accept outside pull requests, but I can provide the full patch if a maintainer wants it.