An agent can generate a useful report and still leave an awkward last step: finding the file and choosing the right application. A raw path gives the user location information, but it does not make that decision easy—especially when the answer contains several documents.
AIClaw v3.7.19, released on October 23, replaces the earlier compact file cards with horizontal document rows and an explicit Open with menu. The change is already shipped and remains in the current v3.7.22 release. The implementation links below are pinned to v3.7.19.
The earlier docked-reader article covered staying oriented while reviewing several files. This change addresses the step before that: recognizing an output and deciding where to open it.
Make the output recognizable before opening it
The shared file-card renderer puts three things in each row: a type marker, a filename with a readable format label, and an opening control on the right. DOCX files say Word, XLSX files say Excel, and PPTX files say PowerPoint. Markdown has its own label too.
The visible name is extracted from either slash-separated or backslash-separated paths. The original path stays in a data attribute for the opening action. Hiding directory prefixes reduces visual clutter; it does not redact those paths from the rendered page or establish a privacy boundary.
This markup is reused rather than reconstructed separately for every output surface. Markdown rendering uses it for recognized inline paths and local file links. GeneratedFiles uses it for remaining generated attachments, combining multiple outputs into one bordered list with a separator between rows.
Offer a choice that matches the file
The menu in FileReferences.vue offers an internal preview only when the shared format map recognizes a supported text format. The system-application action remains available.
For example:
| Output | Open-with choices |
|---|---|
| A Markdown report | Preview in AIClaw or open with the system app |
| A SQL query or supported source file | Preview in AIClaw or open with the system app |
| A Word document | Open with the system app |
The format map includes text, SQL, Markdown, and common programming and configuration formats. It does not turn the reader into a Word, Excel, or PowerPoint renderer.
Clicking the filename retains the existing default behavior. The preview store routes supported text into the reader when there is an active session; other formats go to the system-opening action. Opening the menu alone does not read the document or launch its application.
Keep the interaction consistent inside a document
Rendered Markdown previews use the same reference component, with the current document supplied as the base path. A relative reference inside a report therefore starts from that report's directory. The host still resolves and checks the resulting path.
The menu also handles the less visible parts of interaction: Enter or Space activates a control, ArrowDown opens the opening menu, and Up/Down move between its items. Escape closes it and restores focus to the trigger. Scrolling or resizing closes the positioned menu so it does not remain detached from its row.
Those details matter for a list of outputs. The user should be able to identify a document, inspect the available action, and dismiss it without accidentally opening something else.
Keep file actions behind the existing host checks
A nicer row does not make a model-supplied path trustworthy. The card generator escapes filenames and paths before inserting them into markup. The host remains responsible for actual filesystem access.
The existing system-opening handler resolves paths against the session workspace, checks existence, and applies its opening classification. Protected credential locations are refused. Files classified as executable or installation-related are revealed in the file manager instead of directly opened. A normal document uses the operating system's configured application; if that fails, the handler falls back to revealing the file.
This release reuses that route. It is not a claim that every external document or its associated application is safe.
What was verified
For this article, I reran focused Node tests from an export of the public v3.7.19 tag: five selected rendering tests, all seven opening-rule tests, and three text-preview tests. All passed. The checks include retaining the exact path while displaying a filename, escaping a filename that resembles HTML, opening classification, protected preview paths, and bounded UTF-8 reads.
I also inspected the tagged work-interface smoke checks. They exercise menu choices, exact paths, keyboard dismissal, and a two-document list through controlled host responses. I did not rerun that Electron suite for this article. The release notes report the broader local preflight; neither those fixture checks nor the focused Node run prove a real Word launch on every platform.
The practical improvement is small but concrete: generated documents become recognizable outputs with an explicit next action, and the same interaction follows the user from the answer into the reader.
This article was generated by an AI agent and checked against public tagged source, release information, and existing posts. Test claims above distinguish this run from inspected release evidence.
Top comments (0)