Dawn Web now includes a files browser for the things Dawn produces. Generated HTML artifacts, images, documents, and other outputs are no longer just attachments hanging off a single message — they are first-class items you can browse, search, preview, download, and open from a dedicated view, both at the workspace level and inside an individual thread. File type handling is sharper too, so an HTML artifact looks like an HTML artifact and an image gets image affordances instead of generic blob ones.
The change is small in surface area and large in everyday impact. The conversation is still the place where the work happens. The files browser is the place where the work survives once the conversation has scrolled past it.
Why Files Needed Their Own Surface
Dawn has been getting steadily better at creating things. The agent can draft HTML artifacts, generate images, produce documents, transform inputs into structured outputs, and return results from longer workflows. That capability quietly created a new problem: once the conversation moved on, the file was awkward to find again.
Until this update, the easiest path to a generated file was to be looking at the message that produced it. That was fine for an immediate download. It was awkward for any of the natural follow-up actions: comparing two versions of an artifact, opening the same file in a different tool, finding the image Dawn generated for last Tuesday’s support article, or going back to a draft document a teammate has just asked about. Every one of those tasks required scrolling through the thread looking for the right message — sometimes across several threads — and that friction grew as the thread grew.
Generated work needs a place to live after the message scrolls away. That is what the files browser is.
A View That Treats Files Like Files
The new Files view in Dawn Web is the workspace-level entry point. Open it and you get a clean list of files Dawn has produced and the attachments that flowed through threads, with the metadata you actually need to recognise them: the file name, the owner context, the related prompt or thread information, an indication of age, the size, and the file type.
That metadata is not decoration. The reason “which version of the landing page mockup was the latest one?” used to be hard to answer was that the only signpost was the surrounding chat. Surfacing the prompt and the thread alongside the file turns recognition from “scroll until I find it” into “scan the list once”. The same applies to “where is the image from that support article?” — you do not need to remember the exact wording of the message, only enough about the work to spot it in the list.
The view is intentionally designed to look like a workspace tool, not a raw attachment table. There is a list view and a grid view, refresh stays current as new generated files appear, and the sort defaults make recent activity easy to surface. Browsing is not the only mechanism — search and filtering carry the load once the history grows past a glance — but it is a perfectly usable starting point when you remember roughly when a file was created and not much else.
Inside a Thread, the Same Idea Stays Local
The same model applies at the thread level. Inside a chat, the thread files panel opens from the chat header and shows only the files associated with that conversation, in the same shape as the workspace view.
This is the version that matters most while you are iterating. When you are working through several drafts of an HTML artifact, the prompt, the response, and the file list want to be visible in the same context. The thread files panel keeps them together. You can preview a draft from the panel without leaving the conversation, ask Dawn for the next iteration, and open the new version side-by-side without losing track of what came from where.
The two views complement each other rather than duplicating. The workspace Files view answers “where is that file?” across everything you have done. The thread files panel answers “what has come out of this conversation so far?” while the conversation is still live. You typically reach for the second one while you are working and the first one when you are coming back to something you did before.
Preview Before You Download
Downloading still works, but it should not be the only way to inspect a result. The browser previews the file types Dawn most often produces, directly in Dawn Web.
HTML artifacts open in a preview pane so you can see the page without saving it to disk. Images render visually so you do not have to download three files to figure out which one is the right one. Text-like outputs open in a quick reader instead of forcing a download for files you only want to glance at. When a file is genuinely better handled outside the browser — large binaries, formats that need a desktop viewer, anything where the round trip to disk is the right move — the download action stays exactly where you would expect it.
The reason previews matter so much is that the files browser is most useful in the middle of an iteration loop. If Dawn produces three versions of an HTML artifact in the same thread, the natural next step is to look at them, decide which is closest to the goal, and continue from there. A workflow that requires three downloads, three folder switches, and three browser tabs to compare those versions kills the loop. A workflow where you preview them in place keeps the loop alive.
Search, Filter, and Sort
Browsing alone is not enough once the history has any depth. The browser includes the controls you would expect: search, filtering, sorting, refresh, and a choice of list or grid layout.
Search is the right tool when you remember the file name or some of the prompt that produced it. Filters narrow the list by type when you know roughly what you are looking for — show me the HTML artifacts, show me the images, show me the documents. Sorting helps when the question is about recency, name, or size rather than identity. Refresh keeps the view current after a new generated file lands while you have the page open.
The browser is not trying to be a document management system. It is trying to make generated work easy to find at the moment you need it. If Dawn created the file, Dawn should give you a clean path back to it.
Sharper File Type Handling
The browser also benefits from better file type handling under the surface. Generated outputs and conversation attachments now carry clearer type information, which feeds both the icons and the actions the browser offers.
That sounds incidental until you use the file list every day. An HTML artifact that the system thinks is a generic blob does not get the preview treatment it deserves. An image that lacks proper type information gets a download action where it should get an inline render. Text outputs that the system cannot classify do not pick up the right reader. Cleaner type handling means the browser feels responsive to what the file actually is, not to a lowest-common-denominator default.
It also improves the rest of Dawn slightly. The same type information shows up wherever a file is referenced, including in thread messages, so the affordances follow the file from the moment it is created.
Personal and Thread Context Stay Intact
Files in Dawn live inside the user and thread context they came from. The browser is built around that, not around it.
A file generated in a private thread should not behave like a shared workspace asset just because it came from the same agent in the same workspace. The browser respects the surfaces where files were created, so people see the generated work that is relevant to their conversations and their permissions, and not the generated work that belongs to someone else’s private thread. That is a small but important distinction in any workspace where Dawn is used across both shared and private conversations — the kind of distinction that, if it leaked the other way, would be the part everyone remembered.
The same logic applies to teammates. The browser is a workspace tool, not a public dumping ground. The files that show up are the ones the current user has the right to see; the ones they do not, do not.
How the Browser Fits With the Rest of Dawn
The files browser composes with the other recent additions to Dawn rather than overlapping with them. A long-running generation that lands as a background task produces a file the same way a synchronous response does, and the file shows up in the browser once the task completes. An artifact produced by a scheduled task is browseable alongside everything else. A memory page drafted by /web-research and saved into the workspace is separate work — memory is for durable knowledge, files are for outputs — but the source artifact is still in the browser if you want to look at it again.
The point is not that the browser is doing anything other tools could not. It is that having a single, clean surface for “the files Dawn made” closes a loop the conversation alone could not.
Getting Started
Open Dawn Web and use the Files entry to browse generated files at the workspace level. Inside an agent chat, open the thread files panel from the chat header to see only the files tied to the current conversation.
From there, search for a file when you remember a name or a prompt, filter by type when you know what shape you are looking for, preview the supported outputs without leaving the page, download what needs to live on disk, or open the artifact in the right viewer when it deserves more than a quick glance. The next time Dawn creates an HTML page, an image, a report, or a transformed file, you will have a clean path back to it.
Files also got a broader update — see Files, Attachments, and Previews for the mention-and-preview improvements that complement the browser.