A file name in an agent answer can mean two different things: an output the user should open, or a detail the answer is discussing. Turning both into file controls makes prose harder to read. It is especially distracting in a heading, where a directory path can become a short filename with a dropdown arrow.
AIClaw 3.10.1 narrows automatic file-card rendering to standalone references. The release is published; the code and tests linked here are pinned to that version.
The earlier article about opening generated documents described file rows and their opening menu. This update addresses a different decision: when that control should appear at all.
Mentioning a file is different from delivering it
Consider this illustrative Markdown:
The results are in `report.md`; compare them with yesterday's run. `report.md` In the first paragraph, the filename stays inline code. In the second, the standalone reference becomes a file card. A heading containing ~/Library/Caches/go-build also retains its complete code text instead of becoming an opening control labeled only go-build.
The distinction applies to local Markdown links too. A link embedded in a sentence keeps its visible label without a file-opening action. A standalone local file link can still produce a card. Titles and table cells do not become attachment rows just because they contain a path.
This does change how an answer should deliver several files: each intended attachment needs its own standalone paragraph, or a list item containing only that reference. Putting two links in one sentence does not make an attachment list.
Use Markdown structure before path recognition
The Markdown renderer already has a path-shape check. It recognizes plausible extensions and explicit path prefixes while excluding command lines, URLs, and several ambiguous forms. That check remains useful, but path shape alone cannot tell whether the surrounding text is a title, explanation, or delivery.
The new core rule runs after Markdown inline parsing. It checks whether the inline token belongs to a paragraph and whether, after ignoring whitespace-only text, it contains exactly one inline-code token. Only that candidate receives the standalone-file marker. The inline-code renderer requires both that marker and a recognized path before producing a card.
Local Markdown links follow a similar context check. When a link has surrounding content, or belongs to a heading or table cell, the rule removes its opening and closing link tokens while retaining its label tokens. An eligible standalone link instead goes through the shared card generator.
This is a deliberately narrow structural rule. It does not scan every bare word for filenames or classify every visually separate line as an attachment. The code works with parsed paragraphs, so blank lines matter.
Preserve actual deliveries and explicit images
The change does not remove the existing open and preview actions for standalone cards. Their visible names can remain compact while the exact path is retained for the existing action route.
Explicit Markdown image syntax still follows the image renderer. A supported local image can therefore remain visible inline even though an ordinary filename mentioned in prose no longer becomes a file control. This update does not add an extra generated-image gallery.
The renderer also does not check whether a recognized file exists. Card eligibility is a presentation decision. Actual file access still goes through the application's existing host validation; recognizing a path is not permission to open arbitrary content.
What the regression evidence covers
For this article, I verified the renderer and rendering-test files against GitHub's public 3.10.1 source and ran the renderer test suite from a clean checkout at the release commit. 412 tests passed, one was skipped, and none failed.
The rendering tests cover complete paths in headings, filenames inside sentences and parentheses, local links in prose, table references, standalone references and list items, multiple inline filenames, command recognition, and explicit image handling. They also retain checks for escaped filenames and exact paths in generated cards.
The release notes separately report successful desktop build and type checks and 376 passing work-interface checks. I did not rerun that Electron suite for this article. Its public smoke script uses controlled host responses to check that sentence references remain code while standalone cards still open and preview through the expected route. That is not a claim of real application launches on every platform.
The practical result is less surprising prose: discussing a file leaves the sentence intact, while presenting a file on its own still gives the user an explicit next action.
