Session Files & Links (what this session made)

What it is

What it is: a read-only, per-session list of every file the agent created or edited in that conversation and every link it handed you — newest first, one row per file or link, each one clickable. It answers "the agent made me a thing twenty minutes ago and I've scrolled past it — where is it?"

Where it lives: a Files button in the session header, sitting with Read Aloud and Archive at the top right. Click it (or press Ctrl+Shift+O) and the panel opens under the button. It appears on desktop and on your phone, which is deliberate — see Why mobile matters below.

Where to find it

Availability

Off by default. Turn it on in Settings → Labs (search for "files and links"); the button and the keyboard shortcut both stay hidden and inert until you do.

How it behaves

What each half shows

Files — every path the agent wrote or edited, deduplicated, newest first. A file edited five times is one row, stamped with the last time it was touched and a quiet "edited 5 times". Clicking a row opens the file exactly as clicking that path in the chat does, so the same project-scope permission check applies; nothing new was invented to open files.

Links — every link the agent presented to you: a proper labelled link, or a link it put on a line of its own. A URL mentioned in passing inside a shell command is deliberately not a link. That rule is measured, not stylistic: on a real session the permissive "any URL" reading produced 357 rows, nearly all of them internal API addresses typed inside curl commands, against 2 genuine artifacts. Ignoring code blocks alone did not fix it (357 → 355), because agents write endpoints in ordinary prose. Counting only presented links reduced five real sessions to 1, 2, 1, 1 and 3 rows — each a real share link or deployed page.

Why mobile matters

On a phone there is no file explorer at all — the file tree is a desktop-only sidebar. Until this panel, a link in the chat was the only route to something a session had produced, which is exactly what the feature request that prompted this described. So the Files button is a real header button rather than a "pin it to the session bar" item: pinned bar commands are switched off on mobile by design.

What it does NOT capture

Files created by a shell command are not listed. The list is built from the agent's own file-writing tool calls, which record a filename. A file produced by a redirect inside a Bash command (cat > notes.txt, cp, tee, a heredoc) records no filename and cannot be picked up. The panel says so on screen rather than presenting a partial list as complete — worth knowing, because in this codebase's own sessions Bash calls outnumber file-writing calls by roughly five to one.

A session whose transcript has rotated (a very long conversation that compacted) shows files from its current transcript only. Links are unaffected — they come from saved messages.

A session run on a non-Claude engine has no transcript to read, so it shows links only, and says so plainly instead of rendering an empty file list that would read as "nothing was created".

For agents

How it works

Nothing is stored. There is no table, no migration and no background tracker — the list is worked out on demand each time you open the panel, from two sources the app already keeps: the session's CLI transcript (for files) and its saved messages (for links). That means it can never drift out of sync with what actually happened, and it added no data to your database.

Both halves are independent: if the transcript can't be read you still get links, and if the message store hiccups you still get files. Any managed secret sitting in a path or a URL is scrubbed before the list leaves the main process.

Related

• Peek viewer — how a row opens a file without leaving the session.
• Run a file from chat — right-click a runnable path in a message to launch it.
• File Explorer — browsing a project's files from the sidebar.