AIClaw Now Returns Tool Output Attachments You Can Actually Download

AIClaw already let agents run tools, generate files, and continue working across steps. The weak point was the handoff back to the user: a tool might create a report, image, or data file, but the final answer did not always make that output obvious or directly downloadable.

Recent AIClaw changes tightened that workflow. Tool-generated files are now collected, deduplicated, exposed in API responses and streaming completion chunks, linked into the final assistant message, and rendered by the chat UI through stable /public/files/<uuid> download URLs.

This is not a cosmetic change. It closes the loop between tool execution and user-visible results.

The problem

In a tool-using agent system, “I created the file” is not enough. Users need to:

• know that a file was produced
• see which final answer it belongs to
• download it without searching through logs
• keep that file associated with the conversation history

Without that, generated artifacts are easy to lose, especially when an agent uses multiple tools or delegates work to sub-agents.

What changed in AIClaw

The recent attachment work is visible across the backend and frontend.

On the execution side, AIClaw now:

• collects file outputs returned by tools
• scans sandbox directories for newly created files when a tool does not explicitly return a file result
• pulls generated files back out of sub_agent results
• deduplicates attachments before the final response is stored or streamed

You can see that in the tool execution path:

• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/tool_call.go
• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/executor.go

The final assistant response now appends an attachment section with Markdown links such as:

Attachment List:
- [report.csv](/public/files/<uuid>)
- [chart.png](/public/files/<uuid>)

In the current Chinese codebase revision, that section is rendered as 附件列表 in the saved final content.

The response payload also includes files directly:

• blocking chat responses now return files
• streaming done chunks now include files

That path is visible in:

• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/model/message.go
• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/handler/chat.go
• /Users/yu/go/src/github.com/chowyu12/aiclaw/web/src/api/chat.ts

On the frontend, the chat view turns those file objects into clickable downloads through /public/files/${file.uuid}:

• /Users/yu/go/src/github.com/chowyu12/aiclaw/web/src/views/chat/Index.vue

Why this matters in practice

This feature is useful anywhere an AIClaw agent produces artifacts instead of pure text.

Examples:

1. A code_interpreter task generates a CSV and a PNG chart.
2. A browser automation flow saves a screenshot or extracted document.
3. A sub-agent writes a research summary file and passes it back to the parent run.
4. A shell command creates a log bundle or transformed dataset in the sandbox.

Before this improvement, users could still end up asking, “Where did the file go?”

Now the expected workflow is much cleaner:

1. The tool runs.
2. AIClaw captures the output files.
3. The final answer includes explicit download links.
4. The API and streamed completion both carry the file metadata.
5. The UI renders the attachments as part of the conversation result.

That means AIClaw behaves more like a practical work system and less like a text-only chatbot that happens to call tools.

A small detail that matters: sub-agent outputs

One useful part of this change is that file outputs are not limited to the top-level agent.

The executor now extracts file references from sub_agent results and folds them back into the parent response. That matters because many real AIClaw workflows split research, scraping, or data prep into delegated tasks. If child artifacts disappear at the parent boundary, the system feels unreliable.

Bringing those files back into the parent answer makes nested agent execution much easier to trust.

Another practical improvement: better streaming behavior

The same change set also adds SSE ping support in chat streaming handlers. That is separate from attachments, but it helps long-running tool workflows stay alive while the agent is still working.

For attachment-heavy runs, that pairing is useful:

• streaming stays active during long tool work
• the final done chunk can carry the generated files

Why I picked this feature

This is a good example of AIClaw’s local-first, tool-oriented design philosophy. The platform is not just trying to produce a nice paragraph. It is trying to complete work and return the artifacts that work produces.

Generated files are often the real output. Making them first-class in the response path is the right move.

If you are building with AIClaw, this is the kind of feature that improves daily usability more than another abstract prompt tweak.