Artifact panel: see what a thread or project actually produced

[zds-xiaoxin]

Before submitting

• I searched existing issues and discussions and did not find a duplicate. Related: Show files the agent touched outside the workspace (e.g. /tmp) in the Files tab, especially for No project threads #16333 (files touched outside the workspace in the Files tab), Thread-wide navigation for images, media, and file attachments #9609 (thread-wide media navigation), [Feature]: Files panel: reveal file in Finder (local) / download file (remote) — copying the path is possible but there's no way to actually get to the file #6894 (getting at files from the Files panel), Subagent support as nested threads #6689 (subagents as nested threads).
• I am describing a concrete problem or use case.

Area

apps/web

Problem or use case

I use T3 Code for more than code: generated images, rendered HTML pages, documents, data exports. These outputs end up spread across the transcript as tool results, file paths in command output, and attachments. To answer "what did this thread produce, and where is it?", I scroll the conversation or go hunting in Finder. When several projects run in parallel, this happens all day.

The Files tab browses the workspace, but the workspace mixes outputs with everything that already existed, and outputs written elsewhere are missing (#16333). The diff panel shows code changes, but not images or rendered pages. Media preview steps through one message's attachments (#9609). Nothing shows the products of a thread or project in one place.

Proposal

An Artifacts panel next to the existing side panels:

• Collects what a thread produced: generated images, rendered pages, files the thread wrote or modified, and attachments. Shows thumbnails, file name, time, and size, grouped by day.
• Scope switch: this thread / this project. Filters by type (all, images, …).
• Preview an artifact, compare two side by side, and re-attach an artifact to the composer to ask for a change. This closes the loop: find the result → look at it → continue from it.
• Only include real products. A file that was merely mentioned in a thread (for example an old path printed by ls) is excluded unless it was modified after the thread started. Attachments, rendered HTML, and file changes are always included. Without this rule, the panel fills up with old files.

How this relates to the open ideas: #16333 proposes recording the paths a thread touched outside the workspace. That same per-thread record is what an artifact view needs, so the two could share one server-side source. #9609's thread-wide viewer could be the preview surface for the panel. This proposal adds the summary view: one list of what was produced, across threads in a project.

Prototype screenshot with fictional data. The UI text is in Chinese: 产物 = Artifacts, 本会话 / 本项目 = this thread / this project, 全部 / 图片 = all / images.

Smaller related point: fold subagent threads under their parent

This overlaps with #6689, so I only add one data point from daily use. In my fork, subagent threads no longer get their own sidebar rows. The parent shows ⑂ N and expands in place. An approval or question from a subagent still surfaces and opens the subagent thread directly, while its routine results do not, because the parent agent consumes those. With several delegated tasks per thread, this kept the sidebar readable.

Prototype and limits

I built a working version in a fork: https://github.com/labixiaoxins/t3code-artifact-wall (branch community/artifact-wall-2752, based on 0.0.46-nightly.20261006.2752; the features are one commit, so the diff is easy to read). It passes the repository type check and the web test suite, and I have used it daily on macOS for a few days.

Limits: I have no long-term stability data, did not test Windows/Linux, very large artifact folders, or remote environments, and the UI strings are Chinese only. I am not asking you to merge the fork. I am asking whether this direction fits T3 Code, and if so, what the smallest acceptable version would look like.

Questions for maintainers

1. Should artifacts be a separate panel, or a filter or mode of the existing Files tab?
2. Is "files created or modified after the thread started, plus attachments and rendered pages" an acceptable definition of an artifact, or should it come from a server-side record of touched paths (as in Show files the agent touched outside the workspace (e.g. /tmp) in the Files tab, especially for No project threads #16333) or from providers reporting artifacts explicitly?
3. Is project-level scope wanted, or only per-thread?

[romanzdk]

I built a small first step toward this and would like a maintainer OK on direction and scope before I open a PR.

What it does

• A Resources section in thread details (web, desktop, mobile) that lists files, artifacts and links saved for the thread.
• Users add them with the + button. Agents add them with a new add_resource / remove_resource action on the existing t3_thread_update MCP tool, so an agent can register the report or HTML page it just made.
• Files open in the existing file preview. Links open like PR links (system browser, Cmd/middle-click, right-click to copy).
• The list is part of the thread, so it syncs across clients. It is only sent with the open thread's details, not with every sidebar update.

What it does not do

• No automatic collection from tool output, no project-wide view, no thumbnails or side-by-side compare. Those could build on the same per-thread list later.

Branch: https://github.com/romanzdk/t3code/tree/feature/thread-resources-panel

Before	After

Is this direction OK, and is this the right scope for one PR?

[zds-xiaoxin]

Thanks for picking this up! As the original requester, I think this is a sensible scope for a first PR.

I’ve continued using and updating my local artifact panel, now on v0.1.1. My version includes thread/project scope, type filters, previews, image comparison and reattachment. Those features are useful, but I don’t think they all need to land together.

An explicit per-thread resource list seems like a good foundation. Agent registration through MCP could also provide clearer provenance than inferring everything from paths in tool output.

My main usability concern is making registration part of the normal agent workflow: when an agent produces a meaningful deliverable, it should register it without the user having to ask separately. Otherwise, users still end up maintaining the list manually.

It would also help to distinguish syncing the resource entry from making the underlying file accessible—especially for local files viewed from another device—and handle missing files clearly.

Thread-only scope seems sufficient initially. Project aggregation, thumbnails and comparison can follow later. My local version also tracks checks against file revisions, but that is a separate enhancement.

From my usage perspective, I support this direction. Maintainers would still need to confirm the architecture and PR scope.

[SouthCarpet]

A related gap on the orchestration side, in case it fits the Resources direction above.

A delegated child can put its answer in an html_render page, but its parent gets only the child's text summary. On main at edc37c96c8 the delegated result text still comes from the child's assistant messages, and task_status carries no reference to pages the child produced. The parent has to read the child's activity with t3_thread_read to find the page, which works but costs another paginated read.

If the child registers its page as a resource, as add_resource proposes, the delegated result and the completion wake could carry that same bounded list of references (kind, title, attachment id, source thread and item), with page contents kept out of the result payload. One source for both the panel and the parent, no second extraction rule.

Would a small server-side step in that scope be welcome once the Resources direction is agreed? No PR exists for it.

[zds-xiaoxin]

Follow-up idea: checks tied to the current artifact revision

Following my reply above, here is a more concrete description of the verification feature in my local panel. I would treat this as a separate follow-up to the initial Resources list, once that direction is agreed.

The problem: a report or generated page can be listed as an output, and an agent can say it passed a check, but the user cannot easily tell which file version was checked. If the file is edited afterwards, an old green result becomes misleading.

A small useful scope would be:

• Show No recorded check / Check passed / Check failed / Changed since check for a file resource.
• Associate a check with an actual completed command record in the producing thread, including its outcome, timestamp and a short description of what was checked.
• Bind it to the file revision; modifying or replacing the file makes the previous result stale. Do not carry a green result across edits just because the path is unchanged.
• Keep command passed, user accepted, and deployed/published distinct. An agent-selected check may cover only part of the requirements.

My local implementation uses a file revision plus a content hash when recording the check, and rejects missing, non-terminal or wrongly scoped command evidence. Local tests cover persistence across a service restart and invalidation after file changes. This is macOS/local-file experience, not evidence of cross-platform or remote parity.

Is this a useful later extension to the resource model? The first Resources PR could remain focused on registration and access.

[pablopunk]

I have a working prototype locally but only for images, I wonder if I should expand it to "artifacts". Right now my prototype is both the images I send but also any image read by the agent (like their own screenshots they take)

CleanShot.2026-11-03.at.13.25.20-compressed.mp4