[FEATURE]: present generated image and PDF artifacts in web sessions #41768

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Feature hasn't been suggested before

• I searched open, closed, and stale issues and pull requests.
• This proposal is related to, but broader than, file download support in [FEATURE]:Download files from web ui #38170 and [FEATURE]: file upload, download and delete in the file manager #39878 / feat(app): add file upload, download and delete to file manager #39879.

Problem

When an agent creates an image or PDF while OpenCode Web is running on a remote machine, the result is only referenced as a filesystem path. The user must open the remote filesystem through another tool or manually transfer the file.

This is especially disruptive for image and document generation workflows, where the generated file is the primary result of the task.

Proposed behavior

Allow an agent to explicitly present a generated image or PDF as a session artifact.

For images:

• render the generated image inline in the session
• open a larger preview when clicked
• support mouse zoom, trackpad/touch pinch zoom, and pan
• keep a visible download action

For PDFs:

• keep a normal file card and download action
• open an optional full-screen preview using the browser’s built-in PDF viewer
• fall back to download when inline PDF viewing is unavailable

Proposed artifact contract

Add a small built-in artifact tool that accepts a project-relative file path.

The tool should:

• accept only supported image and PDF MIME types
• resolve and validate the real path inside the active project
• return only metadata such as path, filename, MIME type, and size
• never embed file bytes or base64 content in the session transcript

The Web UI can fetch the file bytes only when it needs to preview or download the artifact.

Agent behavior

Add a short common system instruction telling agents to call the artifact tool for final image or PDF deliverables explicitly requested by the user.

Intermediate files and incidental files should not be presented automatically.

Security and performance

The prototype currently:

• rejects paths outside the active project, including symlink escapes
• uses the authenticated filesystem download endpoint
• stores no file bytes in session messages
• revokes temporary Blob URLs on cleanup
• limits automatic previews to files up to 20 MB
• allows only same-origin and Blob iframe content for PDF previews

Non-goals

• general-purpose file hosting
• galleries or artifact history
• editing generated images or PDFs
• replacing the file manager
• adding a bundled PDF.js viewer
• automatically presenting every file written by an agent

Related work

• [FEATURE]:Download files from web ui #38170 — downloading files from OpenCode Web
• [FEATURE]: file upload, download and delete in the file manager #39878 — upload, download, and delete actions in the file manager
• feat(app): add file upload, download and delete to file manager #39879 — implementation of the file manager actions and download endpoint

The current prototype is built on top of #39879 and preserves its author’s commits and authorship.

Prototype verification

The local prototype has been tested with:

• remote OpenCode Web behind a Tailscale HTTPS endpoint
• inline image preview and download
• image mouse zoom, double-tap, pinch zoom, and pan
• browser-native PDF preview and download
• authenticated Blob fetching
• project path containment
• targeted unit, typecheck, server-header, and Playwright regression tests

I can provide screenshots or a short recording before opening an implementation PR.

Maintainer feedback requested

Before preparing a mergeable PR, I’d like feedback on two product decisions:

1. Is a built-in artifact tool the preferred contract for generated deliverables?
2. Should the common system prompt automatically instruct all agents to present explicitly requested image and PDF deliverables?

I’m happy to adjust the implementation or split it differently based on maintainer preference.