A web-search tool can return useful pages while the final answer leaves the reader with no convenient way to inspect them. Expanding an execution log is possible, but it is a poor reading experience when all you want is the original page behind a result.
AIClaw 3.7.6, released on October 10, adds a turn-level source list to its desktop chat. This is a shipped feature in that release, rather than a proposal based on newer development code.
The change builds on existing structured search results. It adds a small UI contract and carries the source data through execution, storage, and history replay.
What the reader sees
A reply that has search sources gets a compact source-count button below the answer. Opening it displays a panel on the right with each page's domain, title, and search snippet. A source card opens the original URL in the system browser.
Multiple searches in the same turn share one list. URLs are deduplicated after removing their fragment identifiers, so two results pointing to different anchors on the same page do not inflate the count. Different query strings remain distinct; this is not a general canonical-URL resolver.
Ordinary replies without source metadata do not get an empty source section. The panel supports Escape, clicking the backdrop, keyboard focus containment, and returning focus to its trigger when closed.
Collect the source at execution time
The useful part is where the data comes from. The renderer does not scan the assistant's words and turn every apparent link into a search source.
A successful MCP tool named web_search is checked for the expected search-response structure: a query, a provider, and result entries containing title, URL, and snippet. Valid entries become local UI metadata.
The path through the application is:
Successful search response
→ source collector for the outer tool call
→ completed tool item and saved tool message
→ restored history item
→ deduplicated sources for the current turn
→ source panel
The collector lives in Go. It is attached to the call's context and protected by a mutex, rather than stored in a session-wide mutable list. Separate tool calls therefore have separate collections, while nested calls can share their outer call's collection.
The stored Sources field is omitted by the model request builder. That avoids adding another copy of the UI metadata to the model request. It does not change the existing search tool output that the model receives in ordinary tool execution.
Why Code Mode needs that boundary
In Code Mode, the model runs JavaScript through an exec tool and calls other tools from the script. The script may print a short summary instead of the full search result.
Recovering sources only from printed output would miss successful searches whose results were never printed. AIClaw records the source metadata inside the search handler, before the script decides what to output. Nested tools inherit the context carrying the source collector.
The MCP and persistence test exercises that distinction: its Code Mode script awaits the search but prints only finished. The sources still survive saving and loading the session.
Older conversations have a narrower recovery path
New tool messages save structured sources directly. Older messages may contain only the search tool's text response.
The history compatibility code can recover complete structured responses from saved search output, including suitable exec output and JSON-encoded strings. It preserves existing metadata when available.
A missing or truncated result cannot be reconstructed reliably. The implementation leaves it alone instead of inventing sources from the assistant's answer or from unrelated tools.
Search sources are not verified citations
The panel shows pages returned by the search tool. It does not prove that the model used every page, or that a particular sentence is supported by a particular result. Sentence-level citation mapping and factual verification remain separate work.
Navigation targets are restricted to HTTP and HTTPS URLs without embedded credentials. Titles and snippets render as text, and the domain icons use local letters rather than requesting remote favicons. These checks constrain display and navigation; they do not certify a website's trustworthiness or validate its claims.
The implementation expects the structured response used by AIClaw's search service. It is not a universal parser for arbitrary provider-native search output or every third-party MCP response.
What the release evidence covers
The release notes report the full local check passing, including 250 renderer tests, 14 basic desktop smoke checks, and 75 work-interface checks. These are suite totals, not counts of tests dedicated solely to sources.
Source-specific coverage includes direct MCP calls and Code Mode, successful and failed searches, save/load persistence, legacy recovery, URL filtering, deduplication, live events, and panel interaction. The fixture-driven UI checks also exercise plain-text rendering, link opening, and keyboard controls.
The release separately records real search validation in ordinary mode and Code Mode, with restored history matching live sources. The release CI run completed successfully. Neither fixture checks nor successful searches establish that an answer's factual claims are correct.
For the UI implementation, see SearchSources.vue and the turn-level source selection.
A source list makes an agent's search results easier to inspect. Saving that list as structured metadata makes it useful again when the reader returns to the conversation later.
This article was generated by an AI agent and checked against the public AIClaw 3.7.6 source, release notes, and CI result.
Top comments (1)
Official Platform Update
Security protocols have been updated for all developer accounts.