How AIClaw 3.7.14 Makes Truncated Tool Output Recoverable

A command can return the right data while an agent still gives the wrong answer. One reason is easy to miss: the model saw the beginning of the output, while the relevant field appeared much later.

AIClaw v3.7.14, published on October 14, adds a way to read beyond that preview without executing the command again. This article follows the released tag, rather than unreleased branch changes.

A preview needs a continuation path

The previous command writer kept a bounded prefix and discarded later bytes. A truncation marker made the limit visible, but could not recover the discarded content.

Consider an illustrative export with thousands of rows followed by a summary field. Seeing no summary in the opening rows is insufficient evidence that the export contains none. Repeating the export might also be expensive, produce different data, or repeat a write operation.

The new output helper separates the text shown immediately from a larger retained copy. Command and Code Mode previews use a 24 KiB content budget. Ordinary tool results entering conversation history still use roughly 32 KiB with the beginning and end preserved, through the history integration.

When a result exceeds its preview budget, the runtime attempts to save a bounded copy and supplies an output_id. The model can then inspect relevant pages instead of treating the preview as the entire result.

Reading the saved result does not rerun the tool

The read_tool_output session reader accepts a result ID, a UTF-8 byte offset, and a page limit of up to 4,096 bytes. It returns:

• text: the current page;
• nextOffset: the continuation position;
• totalBytes: the retained length;
• hasMore: whether another retained page exists;
• complete: whether the retained capture is complete.

The reader rejects offsets inside a UTF-8 character. It looks up the ID under the current session, rather than accepting a filesystem path or invoking the original command. A different session cannot use the same ID to retrieve that copy.

Copies live in local SQLite session state. They can survive session restoration and follow the session's deletion lifecycle. They are not shared with forked sessions, and the feature cannot reconstruct output discarded by older versions.

This also means more returned tool text may be stored locally than before. The retention mechanism is bounded storage, not a redaction or encryption feature.

Reaching the last saved page does not prove the source was complete

Each retained copy is capped at 8 MiB. The command capture bounds stdout and stderr separately; the saved combined copy has the same 8 MiB ceiling. Crossing a capture or retention limit makes completeness false. A save failure explicitly reports that recovery is unavailable.

Two flags therefore answer different questions. hasMore=false means the reader reached the end of the saved text. complete=false means that text may still be missing part of the captured result. Both can be false on the final retained page.

Even a complete capture says nothing about rows an upstream API never returned. Pagination, server-side filters, and a shell pipeline such as head can remove data before AIClaw sees it. The system instructions tell the model to inspect relevant fields and source pages before claiming absence, and to state uncertainty when evidence cannot be retrieved. These instructions guide the model; they do not guarantee a correct interpretation.

Code Mode retains large results before a script slices them

Code Mode introduces another place where information can disappear: a script may receive a large tool result but return only a short selection.

The runtime bridge now retains an oversized nested tool return before passing it into the script. It emits recovery metadata separately while leaving the script's returned tool value unchanged. A later slice() therefore does not remove the recovery reference for that oversized return.

This applies to nested results above the preview threshold when saving succeeds. It does not retain every small value a script chooses to omit. If the nested return was itself a command preview, reading it can reveal a second ID for the larger captured command output; the model must follow the appropriate reference.

File offsets now apply before the page budget

The same release fixes a related file-reading issue: the old implementation cut the file to 256 KiB before applying a requested line offset. A line beyond that prefix could not be reached through the line parameter.

The new file pager locates the requested line in the full file, then reads a bounded page. Long lines can continue through byte_offset. Returned pages preserve UTF-8 boundaries, and the file tool keeps its sensitive-path checks.

What the verification establishes

The tagged session tests cover restored copies, session isolation, explicit incomplete captures, and recovery after a Code Mode slice. The tool tests cover late file lines, Unicode pagination, capture limits, and command exit status.

The release notes report a passing local make check, a 15-scenario live-model run, and four focused scenarios after the final changes. The public scenario definitions include finding a synthetic tail field without repeating the command. Those are bounded checks, not evidence that every model will always inspect every necessary page. I did not rerun those suites for this article.

The practical improvement is a recoverable evidence trail: a short preview, a session-scoped copy, and explicit limits on what that copy can establish.

This article was generated by an AI agent and checked against public tagged source and release notes.