Inline chat images outside $HOME fail with asset protocol not configured

[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

#166 is the nearest report. That one is the click-to-open / opener allowlist failure (Not allowed to open path). This issue is the separate inline-preview failure: the same local image is refused by the Tauri asset protocol before it can render in chat.

What's broken

Local images inside an attached project folder do not render inline in chat when that folder is outside $HOME. Berd logs asset protocol not configured to allow the path and the image stays broken, even though the file exists, is readable, and is inside the session cwd.

Steps to reproduce

1. Launch Berd 0.6.2 on macOS.
2. Open a project whose working directory is outside $HOME. The failing path here was an attached project under /Users/Shared/....
3. Confirm the folder is the session cwd.
4. In that chat, have the agent emit a normal markdown image pointing at a real PNG/JPEG inside the attached folder, for example ![alt](/Users/Shared/.../file.png) or a relative path that resolves to the same file.
5. Look at the rendered message.

Model/provider does not appear to matter. Reproduced with existing project images that the agent and the shell can both read.

What you expected to happen

Because the image is a local file inside the attached project / session cwd, Berd should render it inline the same way it does for images under $HOME.

MarkdownImage already resolves local markdown images against the session cwd and then calls convertFileSrc(..., "asset"). That path should be allowed for attached project folders, not only $HOME and Berd's own media caches.

What actually happened

The image does not render inline. berd.log records:

[tauri::protocol::asset][ERROR] asset protocol not configured to allow the path: /Users/Shared/.../file.png

This is not a missing file, a bad markdown path, or a macOS permission problem:

• The same files exist and are readable.
• /usr/bin/open opens them.
• The project folder is attached as cwd.
• The failure is Tauri refusing the asset: protocol for a path outside the compiled scope.

src-tauri/tauri.conf.json on v0.6.2 enables assetProtocol with this scope only:

• $APPDATA/avatars/media/**/*
• $APPDATA/artifacts/media/**/*
• $APPDATA/project-artifacts/media/**/*
• $APPDATA/home-widget-media/**/*
• $HOME/**/*
• $TEMP/**/*

An attached project under /Users/Shared is outside every one of those globs, so inline preview is denied by configuration.

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 render itself. Observed in a Goose chat when the transcript included local markdown images from the attached project.

Relevant log output

[2026-08-21][01:48:12][tauri::protocol::asset][ERROR] asset protocol not configured to allow the path: /Users/Shared/PROJECTS_shared/LALA/content-lab/LANGUAGE/indonesian/production-pipeline/2.keyframes/production-readiness/family-world-packets/ID-WORLD-ID-RESTAURANT-PARMESAN-01/environment-layout/v1/review/preview/clean-plan.png
[2026-08-21][23:26:03][tauri::protocol::asset][ERROR] asset protocol not configured to allow the path: /Users/Shared/PROJECTS_shared/LALA/content-lab/LANGUAGE/indonesian/production-pipeline/2.keyframes/revision-evidence/2026-08-21-family-occupied-hero-first/heroes/03-banyak/ID-FN-030--ms01/candidate-b.png

The same class of path failed repeatedly in this log (41 asset protocol not configured lines). /usr/bin/open on the same machine opens those files successfully.

Screenshots, recordings, or other context

src/features/chat/ui/MarkdownImage.tsx routes local markdown images through convertFileSrc(resolvedPath, "asset") after checking that the resolved path is within the session cwd. The chat UI is doing the intended thing; the asset-protocol allowlist then rejects the file because attached project roots outside $HOME are not in scope.

Related but separate: clicking the same path shows Not allowed to open path (#166). That is the opener plugin allowlist. This issue is only the inline preview / asset-protocol deny.

Workaround that works today: copy or symlink the image into $HOME (for example ~/Downloads) and link that copy instead.