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

Start with src/features/chat/hooks/useArtifactLinkHandler.ts and src/features/chat/hooks/ArtifactPolicyContext.tsx, then inspect src-tauri/capabilities/default.json and the attached-folder handling. Reproduce a chat link to a readable file under /Users/Shared and verify that an attached project path opens while unrelated paths remain protected.

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.