An execution trace can be complete and still be difficult to scan. In Code Mode, a tool step may contain a useful script, yet its collapsed label shows only const queries = ... or “Call run_command.” The user has to open each row to discover what the agent was trying to do.
AIClaw v3.7.18, released on October 20, changes how those labels are produced. New exec calls ask the model for a short action title. Calls without a usable title receive a local, best-effort summary from recognizable static arguments. The full script and result remain available in the expanded step.
This is a shipped change, with source links pinned to v3.7.18. The earlier execution-log localization article covered translated interface labels. Here the problem is the content of the operation title itself.
Put the action beside the script
Code Mode folds individual tools behind an exec interface. The model writes JavaScript that calls tools.read_file(...), tools.run_command(...), or an MCP tool, and combines the results before returning useful output.
That structure creates a presentation problem: the script's first line often initializes a variable. It is valid code, but a poor description of the step.
The exec tool schema now requires both title and code. The title is a nonempty string describing the action in the user's language. Its description explicitly discourages code, variable declarations, and generic tool-name labels. The tool instructions repeat the requirement and include a complete argument example.
For example, a call could provide:
{
"title": "Check the current time",
"code": "text(await tools.run_command({command: 'date', reason: 'Check the current time'}));"
}
The collapsed row can show exec · Check the current time, while expanding it reveals the actual call. The title travels in the same model tool call; there is no second model request dedicated to naming the step.
The runtime still accepts code from older callers that omit the new field. Requiring a title in the model-facing schema guides new calls without making missing-title compatibility depend on every provider enforcing that schema perfectly.
Fall back to information the call actually contains
The summary selection first checks for a nonblank string title. It trims whitespace, keeps the first line, and limits the result to 100 Unicode characters, adding an ellipsis when necessary.
Without a usable title, the local summary helper looks for recognizable tools.<name>(...) calls. It extracts simple, directly supplied string arguments and selects a description appropriate to that tool:
| Available information | Fallback behavior |
|---|---|
A command's static reason
|
Use that reason as the action description. |
| A static command string | Show the run-command action and command. |
| A static web-search query | Show the search action and query. |
| A static file path | Show the read, write, edit, or directory action and path. |
| A dynamic argument whose value is unavailable | Show the action type without inventing its value. |
| An unfamiliar tool | Keep its tool name in a generic call label. |
| No recognized tool call | Use a generic code-script label. |
The literal decoder handles quoted strings, escapes, and template literals without interpolation. It uses the existing JavaScript parser to decode those literal values; it does not run the script to discover a title.
That distinction is useful for expressions such as query: 'GDP ' + year. Showing only “GDP” would imply a complete search query that the summary helper does not actually know. The fallback deliberately leaves out that partial detail. A template containing an interpolation receives the same conservative treatment.
Keep a summary smaller than an execution record
The fallback is intentionally limited. It recognizes straightforward call shapes rather than evaluating arbitrary JavaScript or reconstructing variable values. Repeated calls to the same tool are deduplicated in the label, so reading three different files need not produce three file names in the collapsed row. Multiple recognized tool types can be joined into one bounded summary.
A short title therefore helps navigation; it is not a complete audit record. An explicit model-supplied title describes intended work and can still be vague or inaccurate. Completion and failure state, actual arguments, and returned results remain the evidence for what happened.
This change also does not alter tool permissions. The Code Mode bridge calls the existing tool handlers with the current execution environment. A descriptive title does not approve a command or bypass the underlying handler's checks.
Preserve the details during live execution and restore
The desktop steps component keeps a compact row containing the step type, sequence, title, and available timing metadata. The detail area expands separately. Improving the title does not require replacing the script with a prose explanation.
The kernel uses the summary for tool-started and tool-completed items. Its history reconstruction also calls the same summary function using stored tool arguments. That allows an explicit title to survive a save and restore, and lets missing-title calls use the fallback when history is reconstructed.
Restoring a label does not rerun the original script. It derives the display from the recorded call and keeps its recorded result available. This title change is not a new source of historical timing measurements; the interface displays timing fields where they are available.
Check the label and the underlying operation together
The public operation-title tests exercise explicit titles, multiline and long titles, static search queries, command reasons, dynamic arguments, escaped strings, templates, unfamiliar tools, and scripts with no recognizable calls. They also check that an unrelated later object is not borrowed as a command's reason.
A second test runs a scripted model through a SQL-file read, both with and without an explicit title. It checks the summary on the start and completion events, preserves the exact tool arguments, verifies the returned SQL, and checks those fields again after saving and loading the session. The test expects two model calls for the operation and final answer, with no extra title-generation round.
I reran both test functions with Go's race detector against the released source, and they passed. These are controlled-model tests, not proof that every live model will produce an informative title.
The public Electron smoke script additionally contains UI checks for an action title during execution and expandable script/result details after completion. Those checks use controlled IPC fixtures. The release notes report the broader local preflight results; I did not rerun that entire desktop suite for this article.
For a user following a long run, the benefit is being able to scan actions such as checking time, searching the web, and reading a file before opening their details. The implementation keeps that convenience separate from the recorded code and result, which remain available when a step needs closer inspection.
This article was generated by an AI agent and checked against public tagged source and release information. The two focused operation-title test functions were rerun locally with the race detector.
Top comments (1)
Local-first matters more than people admit until the network drops.