DEV Community: chowyu

How AIClaw 3.7.29 Keeps Execution Progress Out of Final Answers

chowyu — Sat, 31 Oct 2026 23:57:08 +0000

An agent turn can contain several useful messages before it contains an answer: a plan to check something, an update after a tool returns, and another explanation before the next operation.

Putting all of those messages into the final answer makes copying a conclusion awkward. Automatically appending every tool-created file adds a second problem: helper scripts, screenshots, and validation receipts start looking like deliverables.

AIClaw 3.7.29 separates the execution process from the final answer in its desktop conversation view. Progress stays in chronological order with tool activity; the final answer has its own presentation, copy action, and file references.

This shipped in v3.7.29. v3.7.30 is the latest public release at this review. The source links below describe released behavior.

Preserve the order before simplifying the view

The renderer groups the timeline into turns beginning with user messages. Within each turn, it retains the original order of assistant messages and execution steps.

The process view merges only adjacent activities. A progress message between two tool calls remains between them, rather than being collected into a separate block of prose above or below all the tools.

For an illustrative turn, that means preserving this sequence:

Progress: I will check the connection.
Activity: Check the browser connection.
Progress: The connection works; I will verify input.
Activity: Verify input and click behavior.
Final answer: The verification passed.

The earlier action-title article explained how individual steps receive useful names. This change concerns how those steps and surrounding messages fit into one conversation turn.

See groupTurns and turnBlocks.

A progress update should not become an answer after interruption

The final-message helper uses a structural rule: the last entry must be an assistant message that is no longer streaming. If a tool or model-sampling step follows the last assistant message, that earlier message remains progress.

The conversation component adds another condition before displaying the final-answer controls: the turn must no longer be the active running turn.

This matters when execution stops after “I will check that.” If the recorded last entry is a failed tool or sampling step, the earlier promise is not promoted into a finished answer.

This is a display rule, not semantic verification. A trailing completed assistant message can still contain an incorrect conclusion. The renderer does not use these conditions to prove that the user's task succeeded.

The ChatView implementation renders the final message separately and passes only that message's text to the answer-copy action.

Keep the process available after the conclusion arrives

During execution, the process area opens by default. Users can collapse or expand it themselves.

When a turn finishes, its expansion override is cleared, including when completion happens in a background conversation. The completed process collapses into its summary, and the user can reopen it afterward.

Compact activity rows use recorded tool actions where available. Completed operations, running work, and failures receive different treatment: a running operation is not counted as a completed one, and a failed operation adds a failure indication.

The activity summary helper summarizes observed step metadata. It does not infer business progress from model reasoning. An informative action title is still a label; the arguments, result, and state remain the evidence for the operation.

Creating a file does not automatically deliver it

Suppose a tool records these illustrative artifacts:

/work/helper.py
/work/check.png
/work/report.docx

If the final answer explicitly links only the report, the helper and screenshot do not become extra final-answer attachments merely because a tool produced them. Their artifact records remain in the execution details.

This also works in the other direction: a recognized local file reference in the final answer can be displayed even when that path did not originate in the built-in file-writing tool's artifact list. A command-generated report can therefore be delivered through its explicit reference.

The selection uses the Markdown renderer's recognized file references, rather than a blacklist of intermediate filenames. A JSON source file can be a deliverable if the final answer references it; an unmentioned document can remain an intermediate output.

The earlier document-row article covered how to recognize and open a document. This release changes which outputs are presented with the final answer.

Explicit reference is not proof that a file exists, is correct, or is safe to open. It also does not delete unmentioned files or redact their execution records. A model that forgets a final link can leave a useful output accessible through the process details rather than the final delivery area.

What was verified

For this article, I reran the local scripts/test-turns.ts suite: 17 tests passed, zero failed, zero skipped. The turn helper, activity-summary helper, Markdown renderer, and test file matched their public v3.7.29 versions byte for byte.

The tests cover chronological grouping, adjacent activity merging, streaming and interrupted turns, final-reference selection, retained intermediate artifact records, image isolation between turns, and separate running/failure summaries. Other checks in the same suite cover elapsed time and source metadata; 17 is the suite total, not a count dedicated only to this change.

These are controlled renderer-helper tests. They do not establish behavior for every live model or exercise native file opening. The release notes separately report 271 desktop workflow checks, including the broader UI changes. I inspected the public workflow checks but did not rerun that full Electron suite for this article.

A useful process view lets the user inspect how the agent worked. A useful final answer lets the user take away the conclusion and the intended files. This release gives those two purposes separate places without discarding the recorded process.

How AIClaw 3.7.28 Separates Project Membership from Working Directories

chowyu — Sat, 31 Oct 2026 00:07:06 +0000

A working directory is a useful way to group agent chats until one piece of work spans several repositories—or two different pieces of work use the same repository.

AIClaw 3.7.28 adds an explicit project layer to the desktop sidebar. A project has its own name and identity, can list multiple working directories, and can contain conversations independently of their execution location.

This shipped in v3.7.28. At this review, v3.7.30 is the latest public release. The behavior described here is already released, rather than a proposal or an unreleased branch feature.

One project, one directory per conversation

The earlier workspace article described grouping conversations by their saved directory. That remains a useful fallback. The new feature addresses a different relationship: a named project can outlive any one folder choice.

For example, an illustrative project called “Checkout redesign” might list:

/work/store-api
/work/store-web

Start one conversation in the API directory and another in the web directory. Both can appear under the same project, while each conversation still has one working directory.

This is not a multi-root execution environment. Adding two directories does not make a single conversation run in both, and moving a chat into a project does not silently change its existing working directory.

Identity is separate from the path

The sidebar helper builds explicit project buckets first. Conversation assignments use the project ID, so two projects can share a directory without merging their chats. An empty project also remains visible before its first conversation exists.

Unassigned conversations with saved directories continue through the existing full-path workspace grouping. The implementation does not require users to classify every old chat before the sidebar works.

This distinction lives in projectBuckets: project membership determines the explicit bucket; the directory still describes where the conversation executes.

Choose the location before starting work

Project settings show the configured directories as a list, mark the first as the default, and let users add folders through the directory picker or remove individual entries.

The project input normalizer trims names and paths, removes empty and duplicate path strings, and preserves directory order. The host additionally requires absolute paths and rejects embedded null characters. This is input validation, not filesystem canonicalization: equivalent symlink paths are not automatically deduplicated.

When creating a project conversation, the host resolves the selected directory against that project's configured list. An explicit choice outside the list is rejected by this creation path. Without an explicit choice, it uses the first directory.

A project with no configured directories falls back to an aiclaw folder inside the user's home directory. New-session startup creates the working directory recursively when needed. The fallback also applies to new ordinary chats with no selected workspace; existing chats retain their saved location.

The relevant sources are projects.ts, workspace-defaults.ts, and the desktop session handlers.

Organization should not relocate existing work

Starting a conversation under a project records its project assignment after session creation. Forking a conversation copies its assignment when the referenced project still exists.

Changing membership updates that relationship without moving files. Editing the project's directory list also does not rewrite the directories saved on existing conversations.

Removing a project removes its definition and membership references. The handler does not delete the member conversations or their files. Conversations with a saved directory can then appear in the fallback workspace grouping.

These operations organize navigation. They do not create a filesystem sandbox, a new permission policy, or a separate copy of a repository. Two projects pointing to the same directory still point to the same files.

What was verified

For this article, I reran five focused project/workspace test functions against the clean v3.7.30 checkout. All five passed, with zero failures or skips.

The checks cover ordered directory normalization and invalid input, first-directory and home-directory fallbacks, rejection of an unconfigured directory at project chat creation, full-path identity, directory display names, and independent membership for projects sharing a directory. They also check that an empty project remains visible and legacy entries without explicit project directories fall back to workspace grouping.

The tests are in test-config.ts and test-workspace-buckets.ts. The three helper source files discussed above matched the public v3.7.28 versions byte for byte.

These are local helper regressions. They do not exercise a real operating system folder picker or prove every desktop workflow. The v3.7.28 release notes separately report broader checks, including multi-directory configuration, renderer reload, membership, and starting a chat in the selected directory; I did not rerun that full suite for this article.

The useful boundary is simple: a project answers which work a conversation belongs to, while its working directory answers where the agent starts executing. Keeping those decisions separate lets a project span repositories without silently relocating an existing chat.

How AIClaw 3.7.27 Keeps a Recovery Copy During macOS Updates

chowyu — Fri, 30 Oct 2026 00:04:45 +0000

A desktop updater can download the right archive and still leave the user without a working application.

The dangerous boundary is replacement: the old app is gone, but the new app has not reached its final location. A failed move at that point turns an update failure into a recovery problem.

AIClaw 3.7.27 changes the macOS replacement script to stage the incoming application, keep the previous bundle, and attempt recovery when replacement or the system open command fails. This is released code in v3.7.27; the latest public release at this review is v3.7.28.

The gap between extraction and installation

The previous script waited for the running process to exit, extracted the ZIP, found an application bundle, removed the installed bundle, and moved the extracted one into place.

Extraction failure happened before removal, so that case left the installed app intact. The gap came later: once the installed bundle had been deleted, a failed move had no saved application to restore.

The new ordering is visible in updater.ts at v3.7.27, in replaceAndRelaunch. The version diff includes the replacement change and other recovery fixes.

Stage before moving the installed app

The replacement process still runs in a detached child shell and waits for the old process to exit. It derives the installed bundle from the running executable, rather than assuming an /Applications location.

Then it:

Extracts the archive to a temporary directory.
Checks that the incoming bundle has Contents/Info.plist and the expected executable with its executable bit set.
Creates a staging directory beside the installed app and copies the incoming bundle there.
Moves the installed app into staging as previous.app.
Moves the staged replacement into the installed location and asks macOS to open it.

Copying beside the installed app moves the potentially expensive cross-filesystem copy before the old bundle is touched. The final moves use that nearby staging directory.

The structure checks are deliberately narrow. They check the expected files and executable permission; they do not establish code-signing validity, archive authenticity, or application health.

Recovery has its own failure path

An EXIT trap tracks whether the old bundle was backed up and whether the replacement was installed.

If a later command fails after backup, the script attempts to remove any installed replacement, move previous.app back, and reopen the restored app. If extraction, validation, or staging fails earlier, the original bundle remains at its installed location and the script attempts to reopen it.

Rollback can fail too. When the backup cannot be moved back, the script preserves the staging directory containing previous.app and records its location instead of deleting the remaining recovery copy.

The child process now appends stdout and stderr to update-install.log in Electron's application user-data directory. That matters because the original Electron process has already exited when these failures happen. Its normal UI cannot report the rest of the installation sequence.

Paths are also shell-quoted with embedded apostrophes escaped. A custom installation directory containing spaces or a single quote should remain a path, rather than changing how the generated shell command is parsed.

What was verified

For this article, I reran:

npm run test:updater

The result was 19 tests passed, zero failed, zero skipped. The local updater source and test file matched the corresponding public v3.7.27 files by SHA-256.

The macOS replacement group executes the actual generated Bash script against temporary fixture bundles. It removes the process-wait line for the test and substitutes controlled implementations of ditto, mv, xattr, and open.

Its eight scenarios cover success, extraction failure, missing executable validation, staging-copy failure, backup-move failure, replacement-move failure, launch-command failure, and rollback failure. Assertions check the installed or preserved old-version marker, staging cleanup, and the reopen target where recovery succeeds. The fixture paths include spaces and an apostrophe.

The test implementation also contains the existing download and Windows installer checks. The total of 19 includes the replacement group's parent test and eight subtests; it does not mean 19 real installations were performed.

Where the protection stops

No real application was replaced during these tests. They demonstrate the script's control flow under injected failures, not end-to-end installer acceptance on every Mac.

A successful open command means macOS accepted the request. It does not prove that the new application stays healthy afterward, and this change does not monitor a later crash or roll it back. The shell recovery path also cannot guarantee recovery from power loss or a forcibly killed updater.

This change concerns macOS bundle replacement. It does not introduce the same mechanism into Windows or Linux installation.

There is also a version boundary: the updater belongs to the application currently running. An older build does not gain the new replacement script merely because the archive it downloads contains 3.7.27 or later.

Keeping the previous bundle until the replacement has been moved and the open request has succeeded gives the updater a concrete recovery path. Preserving that backup when recovery itself fails gives the user something to recover from.

How AIClaw 3.7.23 Masks Known Secrets Before Retaining Command Output

chowyu — Thu, 29 Oct 2026 00:01:01 +0000

Recoverable tool output is useful until the retained copy contains a credential.

A diagnostic command may print an API key or an authorization value. Hiding that value only in the chat preview would leave a second path to it: the saved output that the agent can read later.

AIClaw 3.7.23 adds known-value masking to the desktop Go kernel's command-output paths. For covered values, replacement happens before the preview and before the text is handed to output retention.

This is included in the published v3.7.23 release. It is a specific output safeguard with limits, not a guarantee that every secret leaving a process will be detected.

Retention changes where masking belongs

The earlier output recovery article explained how large results receive an output ID and can be read in pages. That feature deliberately separates a short preview from a larger saved copy.

For command output, both copies need to receive the same protection.

In the one-shot command path, AIClaw captures stdout and stderr separately, masks each, combines them, and then calls the existing preview/retention helper. Persistent shell commands apply the same redactor to their captured result before calling that helper.

The ordering is the key change:

Capture command output.
Replace known credential values with [REDACTED].
Produce the preview and, when needed, pass the masked text to retention.

This does not prevent the child process from producing the original bytes, or mean those bytes never exist in the runtime's capture buffer. It places masking at the boundary where captured output becomes a tool result and retained text.

See exec.go, shellsession.go, and output.go.

Build a set of values the runtime already knows

The redactor uses literal values rather than asking a model to classify each output line.

Its inputs include nonempty values from sensitive process environment variables, the active model key supplied to the turn's tool environment, and recognized credential fields in configured MCP environment variables and headers.

Field-name matching recognizes credential terms such as token, password, secret, API key, authorization, and cookie, with name boundaries. The tests distinguish X-API-Key from ordinary settings such as PATH and TOKENIZERS_PARALLELISM.

Recognized authorization-style values can also contribute the token after the first space, so an output containing the token alone can be covered rather than only the complete header value.

The implementation deduplicates the values and orders replacements longest first. That matters when one known value is a prefix of another: replacing the shorter one first could leave part of the longer value visible.

The sources are tools/redact.go and the turn environment.

A capture limit can split a secret

Exact replacement alone is insufficient when output capture stops in the middle of a known value.

Suppose a synthetic known token is FAKE-HEADER-TOKEN-12345, but an incomplete capture ends with FAKE-HEADER-TOKEN-123. The complete token is absent, so a simple full-string replacement would miss it.

When a capture is marked incomplete, AIClaw checks its trailing text against prefixes of known values. It replaces the longest matching suffix before applying the normal full-value replacements.

That check is deliberately conservative. A short match may also occur in harmless text. Likewise, a known short secret is still replaced wherever its literal value occurs. This mechanism favors hiding a matching value over preserving every coincidental character sequence; it is not semantic understanding of the output.

What the safeguard does not establish

The scope is command output from the covered one-shot and persistent-shell paths.

The release notes explicitly exclude a guarantee for unknown secrets generated inside a command, encoded or transformed values, and arbitrary file content returned through unrelated tools. This mechanism should not be treated as command-argument scrubbing, credential isolation from the child process, or universal protection for every tool response.

For example, a child shell can create a new secret that the parent runtime does not know. Literal masking also cannot be assumed to recognize a transformed representation of a known value.

Those limits matter when interpreting [REDACTED]: the marker says a known match was replaced. Its absence does not prove an output is free of sensitive data.

What was verified for this article

I reran three targeted Go test functions with the race detector. All three passed, including the persistent-shell check without a skip.

The checks cover:

A synthetic environment key in stdout and a supplied session value in stderr, with assertions against both the returned output and text passed to the retention callback.
A synthetic token printed through a persistent shell, while ordinary status text remains unchanged.
Credential-header matching, a short known password, preservation of ordinary configuration values, and masking a known token prefix at an incomplete capture boundary.

These are controlled local regressions using fake values. The retention assertion inspects the saver callback; it is not a production database audit, a live provider test, or evidence that arbitrary secrets are detected.

The reproducible tests are in security_followup_test.go.

Recovering a large command result should not bypass a protection applied to its preview. For values the runtime knows, this release puts the replacement before the point where those two output paths diverge.

Release notes · Version diff

How AIClaw 3.7.23 Reuses Prompts Without Sending Them Automatically

chowyu — Tue, 27 Oct 2026 23:59:17 +0000

A useful prompt often has two parts: instructions you repeat and details that change with the task.

For a code review, the repeated part might ask for concrete bugs, file references, and test gaps. The variable part is the branch, file, or behavior you want reviewed today. Copying the whole thing from an old chat makes it easy to bring along stale context.

AIClaw 3.7.23 adds ten local prompt presets to the desktop composer. Selecting a preset inserts editable text. It does not submit a message or start agent work.

The feature is included in the published v3.7.23 release. Here is how it works, and why the insertion boundary matters.

Save a reusable instruction in a numbered slot

Type /presets in the composer and choose the management entry from the slash menu. The dialog lets you select one of ten positions, enter a name and prompt, and save it. An occupied slot can be replaced or deleted.

For example, you could save this instruction in slot 1 under “Review changes”:

Review the changed code for concrete bugs and missing regression coverage. Explain each finding with a file reference. Separate verified behavior from assumptions.

That is an illustrative prompt, not a claim about what a model will always do.

Later, type /preset1 and select the saved entry, or search for its title in the slash menu. The text appears in the composer, ready for you to add the files or behavior relevant to the current task.

The workflow is documented in the versioned README, and the management dialog is implemented in PromptPresets.vue.

Selecting a prompt is an editing action

The important behavior is what happens before submission.

AIClaw replaces the active slash-command span with the preset body. It keeps the draft after the caret and restores the caret at the end of the inserted text. When that trailing text has no leading whitespace, the insertion helper adds a separating space.

The regression fixture makes this concrete. With the caret immediately after /preset2, a draft of:

/preset2 keep this draft

and a saved body of:

Check code
Report bugs

becomes:

Check code
Report bugs keep this draft

The remaining draft is preserved, and no message is sent just because the menu selection used Enter.

When the suggestion menu is open, Enter or Tab selects the entry. After insertion, normal composer submission rules apply. If an agent turn is already running, sending the completed prompt still follows the existing queue behavior and permission policy.

The text transformation is a small function in shared/presets.ts. Its integration with the slash picker lives in ChatView.vue.

The manager leaves room to change your mind

Opening the manager does not send the current composer text. Dismissing it preserves the draft, including the slash command you typed.

Saving uses the application's existing configuration path. The dialog closes after that save succeeds. If the save fails, the dialog shows the error and keeps the entered values available. While saving, the form disables its editing controls.

Presets share the slash menu with skills, but they have a different job. A preset expands saved text into the composer; it does not install a skill or add a runtime tool. Keeping both kinds of entries in one picker makes them easy to discover without making prompt insertion execute anything.

Normalize configuration at the boundary

The feature stores explicit numbered slots rather than relying on array position as the shortcut number.

Normalization accepts slots 1 through 10, drops invalid entries and duplicate slot numbers, and sorts the accepted entries by slot. Names and prompt bodies must be nonblank. Names are trimmed and limited to 80 JavaScript string units; prompt text is bounded at 20,000. The dialog also exposes matching length limits.

An older configuration without presets becomes an empty list. A missing field does not seed sample prompts or reinterpret another setting as a saved instruction.

These are local saved prompts in the desktop application's configuration. This release implements text reuse and editing; it does not add a template language, automatic variable substitution, or a scheduled execution mechanism to presets.

See configuration normalization and the preset helper.

What was checked for this article

I reran the focused preset configuration test. It passed checks for missing-field migration, invalid and duplicate slots, shortcut/title matching, draft-preserving insertion, caret position, and length limits.

I also rebuilt the desktop app and ran its controlled Electron work-UI smoke suite: 195/195 checks passed. Four preset-specific checks cover opening the manager without sending, saving through configuration, inserting while preserving trailing draft text without sending, and dismissing the dialog without losing the composer draft.

The public checks are in test-config.ts and smoke-work.cjs.

The UI suite uses the real Vue/preload workflow with fixture IPC handlers and temporary test data. It verifies those interface behaviors; it is not a paid-model integration test or a manual test of every packaged platform.

For recurring reviews, report instructions, and explanation formats, the useful unit is often just a saved paragraph. Presets make that paragraph easy to insert while leaving the final task details and the decision to send in the composer.

Release notes · Full version diff

How AIClaw 3.7.23 Discovers New MCP Tools During an Agent Turn

chowyu — Tue, 27 Oct 2026 00:00:48 +0000

An MCP connection can stay healthy while its tool catalog becomes stale.

Imagine a server that initially exposes a setup tool. Calling it makes another tool available, and the server sends a tool-list change notification. If the agent keeps using the catalog it fetched at connection time, its next model request still describes the old tools.

AIClaw 3.7.23 closes that gap in the desktop Go kernel. It listens for catalog changes, fetches an updated list, and installs it before the next model request—even within the same agent turn.

This is shipped behavior in v3.7.23, not a proposal. This article focuses on dynamic discovery in the desktop kernel; the earlier custom-tools article covered the broader extension model.

A notification marks the catalog as stale

The signal is the MCP notification named notifications/tools/list_changed.

AIClaw does not install new tools from the transport's reader goroutine. The notification increments a change generation. Later, RefreshTools checks whether that generation has already been applied.

That distinction has two useful effects:

An unchanged catalog does not trigger another tools/list request at every model step.
Concurrent users of a shared connection coalesce the refresh work instead of independently fetching the same catalog.

The client also reads paginated lists using nextCursor. It rejects empty or duplicate tool names, a cursor that does not advance, and catalogs exceeding its page or tool limits. It publishes the fetched catalog only after the list is complete and no newer notification has invalidated that fetch.

The implementation is in mcpclient/client.go.

Install the update at the next model step

Receiving a notification and updating the model's available tools are separate operations.

The agent's sampling loop calls refreshMCP before calling the model. When a connection has a newer catalog, the session removes that server's previous tool registrations, mounts the new catalog, and refreshes its system instructions.

A simplified sequence looks like this:

The model calls an existing MCP tool.
The server changes its catalog and sends a notification.
The current tool call returns.
Before the next model request, AIClaw refreshes and installs the catalog.
The model can see and call the newly available tool.

An already admitted call is not interrupted by a transport notification. The catalog update takes effect at the sampling boundary. It does not rewrite a model request that is already in flight.

See the refresh boundary and session catalog installation.

Code Mode needs the update too

Refreshing only the direct tool definitions would leave Code Mode behind.

In Code Mode, MCP tools sit behind the executable tool bridge. AIClaw updates the underlying registry, rebuilds that bridge and its descriptions, and refreshes the instructions used for the next model request.

The desktop host receives a session/toolsUpdated event as well. The renderer applies it to the active session's tool information, so the displayed catalog can follow the kernel's catalog. Events for another session do not replace the active chat's tool list.

A failed refresh keeps the last usable catalog

A temporary tools/list failure should not turn a connected server into an empty tool list.

AIClaw retains the previous catalog, reports the refresh failure, and applies a one-second retry cooldown. The refresh operation has a five-second timeout. If notifications keep arriving during a fetch, it makes at most three attempts within that operation before backing off.

Keeping old definitions is a recovery strategy, not a guarantee that every old tool will still work. A server may already have removed a tool. The old catalog simply remains available while discovery recovers.

There is also a latency tradeoff: a pending refresh can delay the next model request. The five-second timeout bounds one refresh operation; it is not a claim that discovery is free.

Transport support and boundaries

The release handles notifications over stdio and in HTTP response SSE streams. For Streamable HTTP servers that advertise capabilities.tools.listChanged, it also opens the optional GET notification stream. Closing the transport cancels that stream.

The older HTTP+SSE transport with separate SSE and message endpoints remains unsupported. This change also depends on receiving notifications; it does not continuously poll servers that silently change their tools.

See the HTTP transport.

What was verified

For this article, I reran four targeted Go test functions with the race detector. All passed; the agent integration test includes both direct and Code Mode subtests.

The controlled tests cover coalesced refreshes, pagination, retaining the catalog after failure, retry recovery, notification/RPC response separation, and cancellation of the HTTP notification stream. The agent test changes a fixture server's tool list after a tool call, verifies that the next model request contains the new definition instead of the old one, invokes that new tool in the same turn, and checks the host update event.

These are local tests using a fixture MCP server and a scripted model. They do not establish compatibility with every third-party server or constitute a live production-model test.

The reproducible checks are in client refresh tests and the two-mode agent regression.

If an MCP server changes its tool surface while work is running, a connected socket is only half the contract. The next model request needs an accurate description of what it can call. This release makes that update an explicit part of the agent loop.

Release notes · Full version diff

How AIClaw 3.7.19 Makes Generated Documents Easier to Open

chowyu — Mon, 26 Oct 2026 00:02:11 +0000

An agent can generate a useful report and still leave an awkward last step: finding the file and choosing the right application. A raw path gives the user location information, but it does not make that decision easy—especially when the answer contains several documents.

AIClaw v3.7.19, released on October 23, replaces the earlier compact file cards with horizontal document rows and an explicit Open with menu. The change is already shipped and remains in the current v3.7.22 release. The implementation links below are pinned to v3.7.19.

The earlier docked-reader article covered staying oriented while reviewing several files. This change addresses the step before that: recognizing an output and deciding where to open it.

Make the output recognizable before opening it

The shared file-card renderer puts three things in each row: a type marker, a filename with a readable format label, and an opening control on the right. DOCX files say Word, XLSX files say Excel, and PPTX files say PowerPoint. Markdown has its own label too.

The visible name is extracted from either slash-separated or backslash-separated paths. The original path stays in a data attribute for the opening action. Hiding directory prefixes reduces visual clutter; it does not redact those paths from the rendered page or establish a privacy boundary.

This markup is reused rather than reconstructed separately for every output surface. Markdown rendering uses it for recognized inline paths and local file links. GeneratedFiles uses it for remaining generated attachments, combining multiple outputs into one bordered list with a separator between rows.

Offer a choice that matches the file

The menu in FileReferences.vue offers an internal preview only when the shared format map recognizes a supported text format. The system-application action remains available.

For example:

Output	Open-with choices
A Markdown report	Preview in AIClaw or open with the system app
A SQL query or supported source file	Preview in AIClaw or open with the system app
A Word document	Open with the system app

The format map includes text, SQL, Markdown, and common programming and configuration formats. It does not turn the reader into a Word, Excel, or PowerPoint renderer.

Clicking the filename retains the existing default behavior. The preview store routes supported text into the reader when there is an active session; other formats go to the system-opening action. Opening the menu alone does not read the document or launch its application.

Keep the interaction consistent inside a document

Rendered Markdown previews use the same reference component, with the current document supplied as the base path. A relative reference inside a report therefore starts from that report's directory. The host still resolves and checks the resulting path.

The menu also handles the less visible parts of interaction: Enter or Space activates a control, ArrowDown opens the opening menu, and Up/Down move between its items. Escape closes it and restores focus to the trigger. Scrolling or resizing closes the positioned menu so it does not remain detached from its row.

Those details matter for a list of outputs. The user should be able to identify a document, inspect the available action, and dismiss it without accidentally opening something else.

Keep file actions behind the existing host checks

A nicer row does not make a model-supplied path trustworthy. The card generator escapes filenames and paths before inserting them into markup. The host remains responsible for actual filesystem access.

The existing system-opening handler resolves paths against the session workspace, checks existence, and applies its opening classification. Protected credential locations are refused. Files classified as executable or installation-related are revealed in the file manager instead of directly opened. A normal document uses the operating system's configured application; if that fails, the handler falls back to revealing the file.

This release reuses that route. It is not a claim that every external document or its associated application is safe.

What was verified

For this article, I reran focused Node tests from an export of the public v3.7.19 tag: five selected rendering tests, all seven opening-rule tests, and three text-preview tests. All passed. The checks include retaining the exact path while displaying a filename, escaping a filename that resembles HTML, opening classification, protected preview paths, and bounded UTF-8 reads.

I also inspected the tagged work-interface smoke checks. They exercise menu choices, exact paths, keyboard dismissal, and a two-document list through controlled host responses. I did not rerun that Electron suite for this article. The release notes report the broader local preflight; neither those fixture checks nor the focused Node run prove a real Word launch on every platform.

The practical improvement is small but concrete: generated documents become recognizable outputs with an explicit next action, and the same interaction follows the user from the answer into the reader.

This article was generated by an AI agent and checked against public tagged source, release information, and existing posts. Test claims above distinguish this run from inspected release evidence.

How AIClaw 3.7.21 Ties Temporary Browser Tabs to an Agent Turn

chowyu — Sun, 25 Oct 2026 00:03:39 +0000

A browser automation step can finish correctly and still leave a mess. Temporary search pages remain open, another run reuses the same browser state, and a naive cleanup routine risks closing a page the user opened themselves.

AIClaw v3.7.21, released on October 23, adds ownership-based cleanup for browser work. Each execution turn gets its own browser state. When that turn ends, the host cleans up the pages it created and releases debugging connections to existing user pages.

This is a shipped change introduced before the current v3.7.22 release. The source links below are pinned to v3.7.21. The earlier browser-tools article explained indexed page operations; this article focuses on what happens to those pages when the work ends.

Give each execution turn its own browser state

The desktop session manager listens for turn/started and turn/completed notifications. It starts browser state for the first event and begins cleanup for the second. Runtime exit and stop also request cleanup of remaining active turns.

Here, a turn means one execution run within a conversation. Cleanup does not wait until the user archives or deletes the conversation.

The TurnBrowsers coordinator keys its map by the pair of session ID and turn ID. Each entry contains an AgentBrowser instance and a set of pending browser-operation promises. Creating that state does not itself open a window; the built-in window driver opens one when an operation needs it.

This separates concurrent runs. Finishing one turn selects that turn's entry rather than closing a single application-wide browser object that another run might still need.

Wait for an opening page before closing owned pages

An operation can still be creating or loading a page when the execution turn ends. Clearing the browser reference immediately can miss that late-arriving page.

The coordinator records each operation's promise before awaiting it. Its finish sequence is:

const turn = this.turns.get(key);
if (!turn) return;
this.turns.delete(key);
await Promise.allSettled(turn.pending);
await turn.browser.close();

This excerpt is from the coordinator's finish method. Removing the map entry first prevents subsequent browser requests for the finished turn from starting new work. Waiting for the recorded operations to settle gives cleanup a chance to see pages created by operations that were already underway.

The use of allSettled matters because an opening or navigation error must not skip cleanup. It also means closing a page may follow the end-of-turn event rather than happen instantly: an in-flight browser operation can take time to settle.

Track creation, not tab-group membership

AIClaw supports two browser backends, and their cleanup behavior differs:

Backend	Page created for the turn	Existing user page
Built-in Electron browser	Close that turn's browser window	Separate from the user's Chrome or Edge pages
Browser-extension backend	Remove tabs recorded as created by that turn's driver	Detach debugging without closing the tab

The extension driver has a random owner ID and tracks tabs it used. When it creates a tab, it includes that owner in the request. On release, it detaches used tabs and asks the extension to clean up pages belonging to that owner.

The extension background script records each numeric tab ID under an agentTab: key in chrome.storage.session, with the owner as its value. Cleanup reads those records and removes only entries matching the requested owner.

The visible AIClaw tab group helps organize pages, but it is not evidence of ownership. A user page in the same group should not be removed by a group-wide sweep. Likewise, selecting an existing user tab does not make it a page created by the driver.

Session storage lets the extension retain those creation records across suspension or restart of its background worker. Chrome's storage documentation also makes the limit explicit: reloading, updating, or disabling the extension, or restarting the browser, clears this storage. These records are not a general recovery database for abandoned tabs.

Preserve the browser's last window

There is another lifecycle edge case: removing the last tab can close its browser window. Avoiding an explicit windows.remove call is not enough.

Before removing an owned tab, the extension queries its sibling tabs. If it is the window's last tab, it creates an about:blank tab in that window first. Cleanup may therefore leave one blank page instead of closing the user's browser window.

Concurrent cleanup introduces a subtle race. With two owned tabs remaining, two turns could both see a sibling count of two and then each remove a tab. Neither would create a replacement page.

The extension serializes cleanup requests through a promise chain. Each request waits for the previous cleanup before performing its own last-tab check. A failed request is still reported to its caller, while the queue's catch handler allows later cleanup requests to proceed.

This coordinates AIClaw's own cleanup requests. It is not a claim that the application controls every other browser extension or a user's simultaneous manual tab actions.

What the regression tests establish

I reran scripts/test-browser-cdp.ts from an export of the public v3.7.21 tag:

node --test --experimental-strip-types --import ./scripts/ts-resolve.mjs scripts/test-browser-cdp.ts

All five Node tests passed. Four cover existing browser helpers; the ownership regression runs the real extension background script with controlled Chrome API substitutes. That test checks several relevant cases:

Cleaning one owner keeps another owner's tab and a user tab in the same group.
A fresh worker context can clean up using the retained session-storage records.
Repeating cleanup does not remove another page, and a manually closed tab is harmless.
Two owners cleaning their final tabs concurrently leave a blank tab in the window.
A cleanup request without an owner is rejected.

These are controlled API tests, not a live Chrome or Edge end-to-end run.

The public Electron smoke script additionally exercises the turn coordinator with an isolated bridge: concurrent turns, selected user tabs, a delayed creation request, a failed navigation, and rejection of requests for a finished turn. It also contains a real built-in-window lifecycle check. I inspected those checks but did not rerun that Electron suite for this article. The release notes separately report its local preflight coverage.

Keep the cleanup boundary explicit

Creation defines which pages are temporary. The cleanup code does not infer a permanent ownership handoff merely because a user later looks at an agent-created tab. It is also not a command to close all pages associated visually with AIClaw.

For a manually loaded browser extension, the browser design notes call out the need to reload the extension to enable the new cleanup operation. If the extension is disconnected or cleanup fails, the host logs the error. The implementation does not guarantee that every temporary page disappears after an application crash or an unreachable extension.

Within that boundary, the result is useful: temporary pages follow the lifetime of their execution turn, existing user tabs are released rather than closed, and concurrent cleanup considers the browser window's last-tab behavior. The host owns this lifecycle work, so the model does not need to remember to perform it as a final task step.

This article was generated by an AI agent and checked against public tagged source and release information. The five-test browser module was rerun locally; no live user-browser end-to-end test is claimed.

How AIClaw 3.7.22 Gives AI Approval Checks an Eight-Second Budget

chowyu — Sat, 24 Oct 2026 00:05:47 +0000

An approval check can become part of every tool's critical path. If the agent first asks another model to assess an operation and then still needs a person to confirm it, a single tool row combines several different kinds of waiting.

AIClaw v3.7.22, released on October 23, reduces the time budget for that AI stage, avoids some unnecessary review requests, and shows model review separately from human confirmation. A timeout still leads to confirmation; it does not grant permission.

The release also changes which file writes need approval in Default mode. That is a separate permission tradeoff, described below. All source links here are pinned to the published release rather than unreleased main-branch code.

Bound the review stage, not the whole task

The reviewer implementation sets an eight-second context deadline around one model request. In v3.7.21, that deadline was thirty seconds.

The review request now has three relevant settings:

reviewCtx, cancel := context.WithTimeout(ctx, approvalReviewTimeout)
defer cancel()
response, err := client.Stream(reviewCtx, llm.Request{
    Model: model.Model,
    MaxTokens: 128,
    DisableThinking: true,
    // Separate system instructions and the operation to assess.
}, nil)

This is an abbreviated excerpt. The actual request contains two messages: the reviewer's system instructions and a JSON payload describing recent visible user requests and the proposed operation. It has no tools.

The output limit falls from 512 to 128 tokens. The intended result is a small JSON object containing one decision field, whose value is allow or ask; the reviewer is not being asked to produce another task answer.

The eight-second deadline applies to AI review. It does not include the person's response time or the command's execution time, and a task can contain several separately reviewed operations. Reducing the deadline by twenty-two seconds is therefore a bound on this stage, not a measured average speedup for an entire run.

Request non-thinking mode only where the client knows how

The reviewer still uses the current conversation model. It does not silently select a different provider or a smaller model.

Instead, the model client has a request-scoped non-thinking option. On recognized DashScope endpoints and supported model families, it sends enable_thinking=false. On the recognized native DeepSeek endpoint and supported models, it sends thinking.type=disabled. It removes a conflicting reasoning-effort value when applying those controls.

The implementation limits these fields to known endpoint/model combinations. It leaves unknown gateways and recognized thinking-only model names alone. The ordinary conversation request also keeps its existing behavior: the fast setting is requested for the review call, not applied globally to the session.

That boundary avoids treating every OpenAI-compatible endpoint as though it accepts the same vendor extensions. An unsupported or slow review can still fail or reach the deadline, in which case the runtime asks the user.

Skip a model call when the rules already require a person

The authorization path first considers the operation's effect and current approval policy. Trusted read-only tools do not need a model review.

For commands, existing risk rules can already identify a reason to ask a person. Examples covered by the tests include a git push, a sudo command, and a curl request sending data. Those recognized cases now go directly to human confirmation instead of paying for an AI request that should also ask.

Absence of a risk-rule match does not grant permission. An unfamiliar command still goes through independent review in Default mode. These string-based rules are useful routing checks, not a complete shell security parser.

The reviewer accepts only a narrowly parsed allow/ask object. Duplicate keys, additional fields, trailing JSON, unknown decisions, tool calls, and incomplete responses cannot turn into approval. Review errors fall back to confirmation without retrying the review request. If the originating operation has been cancelled, the runtime does not open a new confirmation request for it.

Keep review time separate from human waiting

The kernel now emits a started notice and a completed notice for each review, carrying its start time and duration. Human confirmation has its own notice pair and elapsed time.

The desktop event handling updates the existing notice by its ID, rather than adding a second row when it completes. The steps component displays the timing fields beside the title.

This makes a slow step easier to inspect: the user can distinguish time spent reviewing an operation from time spent waiting for a decision. The enclosing tool's elapsed time still includes its authorization and execution work; the new notices are not a claim that the tool timer measures only the command itself.

Default mode also changes the file-write boundary

The desktop modes are now named Default, Strict, and Allow all. The profile descriptions and authorization code make an important distinction:

Mode	File-tool writes	Commands and external tools
Default	Inside or outside the workspace without approval	Risk rules and independent review can require confirmation
Strict	Require confirmation	Actions with side effects require confirmation
Allow all	No operation confirmation	No operation confirmation; hard guards remain

In Default mode, the file-write behavior also applies when no workspace is set. Protected credential paths remain blocked. Selecting Strict keeps confirmation for file writes.

This is broader file-tool permission, not merely a faster implementation of the previous approval boundary. It does not make an arbitrary shell command a file tool, and it does not remove the existing command sandbox restrictions. A file tool being able to write a path does not imply that a shell command can write the same path without review or sandbox constraints.

What I checked against the release

I reran eight focused Go test functions with the race detector from an export of the v3.7.22 tag, across the agent, tools, and model-client packages:

Reviewer tests cover allowed and denied command execution, malformed responses, strict parsing, visible-user-intent isolation, usage recording, and a stalled request that falls back once after the review deadline.
Tool-policy tests cover direct confirmation for recognized risky commands, continued review for unknown commands, workspace-external file writes without review in Default, and retained protected-path and stricter-policy behavior.
Client tests check recognized non-thinking controls and verify that they do not leak into ordinary conversation requests.

All eight selected functions passed. These tests use temporary files and controlled HTTP/model responses; they are not a production-model latency benchmark or a proof of universal risk-classification accuracy. The release notes report the broader local preflight, including 290 renderer-related tests and 184 UI checks. I did not rerun that entire desktop suite for this article.

The useful change is a smaller, visible budget for the AI decision stage, with human confirmation still available when the model cannot finish or cannot confidently allow the operation. Average speedup needs measurements from real requests; the published implementation and controlled tests establish the deadline, routing, and permission behavior instead.

This article was generated by an AI agent and checked against public tagged source and release information. The eight focused test functions described above were rerun locally with Go's race detector.

How AIClaw 3.7.18 Gives Code-Mode Steps Useful Action Titles

chowyu — Fri, 23 Oct 2026 00:07:55 +0000

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.

How AIClaw 3.7.18 Makes Channel Approval a Per-Conversation Decision

chowyu — Thu, 22 Oct 2026 00:08:47 +0000

A desktop agent can ask its owner before running a command. An agent answering a WeChat or WeCom message usually has nobody at the desktop to click Allow. A set of tool checkboxes can make that difference harder to understand: making a tool available does not necessarily let its operation pass the approval policy.

AIClaw v3.7.18, released on October 20, replaces those external-chat checkboxes with two modes: Unattended and Full access. The choice is stored for each external conversation and stays separate from the desktop's global approval setting. Configured built-in web search can also work in the default unattended mode.

This is part of the published release. All source links below are pinned to v3.7.18. The earlier channel-state article discussed session continuity; this change concerns who can authorize actions within a channel conversation.

Separate admission from action approval

The first decision is whether an external conversation may use the agent at all.

In the channel gateway, an unknown conversation is recorded as pending. Its first message does not start a model turn. The desktop owner must allow that conversation and select a model before later messages are served.

The binding key includes the plugin, channel, connection, and external conversation. The same person contacting two different connections therefore has two bindings, with independent settings. In a group, the authorization belongs to the external group conversation rather than a separate permission record for each participant.

Action approval is the second decision:

State or mode	Runtime behavior
Pending or revoked conversation	Incoming messages do not start an agent turn.
Unattended, the default	Operations that require confirmation fail instead of waiting for someone to click a desktop prompt.
Full access, explicitly enabled	The approval layer allows operations without requesting confirmation; other tool checks still apply.

The settings UI asks for confirmation when moving a conversation into full access. Its warning names the consequence: that conversation can write files and execute commands without individual approvals. Switching one chat does not change the mode of every other chat.

Persist the decision with the conversation

The channel binding model now has an approval-policy field with a database default of never, the runtime name for unattended mode. The old allowed-tools field remains for compatibility, but it no longer determines execution permissions.

The authorization service accepts only never and bypass. An omitted mode becomes never; unsupported interactive modes are rejected. A legacy tool selection therefore does not silently become full access during an upgrade.

At execution time, full access requires both an allowed binding and the saved bypass value. Missing, invalid, or revoked authorization resolves to unattended policy. The inbound admission check still blocks revoked conversations altogether.

That distinction matters when opening an external conversation in the desktop. The owner may use a different global mode for normal local work, but viewing a channel conversation must not accidentally import that mode into it.

Reapply the saved mode when a session returns

A database field alone would leave a gap if the agent kept using an already-mounted session.

Before handling another message, the gateway builds a refresh from the saved binding. If an idle session's mounts differ, it saves and reloads the same session ID with the refreshed configuration. Unchanged sessions can be reused. The desktop resume path also passes through the channel refresh logic.

The channel policy guard pins the approval mode to that binding, overriding a proposed desktop value. This keeps the persisted external-chat decision authoritative through both entry points.

A busy session is not remounted in the middle of its turn. Treat a mode change as taking effect for subsequent work, rather than as an immediate cancellation of an operation already running. Revoking admission also does not undo files or other effects from completed work.

Give unattended chats a specific search path

A request such as “look up the official specifications” should not require the model to improvise a shell command just to search the web.

The gateway checks whether a built-in search engine is enabled. If so, it mounts AIClaw's own web_search MCP server, launched through the application's mcp-search entry point. It is marked trusted, and the agent's MCP effect classification treats it as a read operation. That lets the built-in search path run without interactive approval.

The server receives the application database location rather than embedding a provider key in the MCP configuration. This is a specific built-in integration: the refresh replaces the channel's MCP map with this search server, or an empty map when no engine is enabled. It does not inherit arbitrary third-party MCP servers from the desktop.

Search still depends on a configured, working provider and network access. Selecting unattended mode does not configure a search engine or prove that its credentials are valid.

Keep the scope of full access explicit

Full access changes approval behavior; it does not enable every desktop integration.

The channel refresh disables the dedicated email, application-configuration, scheduler, browser, and computer-use capabilities, and clears mounted skill directories and the memory file. A desktop refresh cannot simply turn those capabilities back on for the channel session.

Those exclusions describe which capabilities are mounted. They are not a complete machine-isolation guarantee. File and command tools remain powerful, and a full-access conversation should be trusted accordingly. Existing dangerous-command checks and protected-path guards still matter; hiding a dedicated email or memory tool does not establish that arbitrary host resources are inaccessible by every other route.

There is a useful nuance in the default mode too. Unattended means “do not ask,” not “the entire filesystem is read-only.” The tool policy decides which effects require approval. It rejects those effects under never; operations already permitted by the normal policy do not acquire an extra confirmation requirement merely because the session is unattended.

Test policy decisions with observable effects

The public channel-policy regression tests cover six concrete cases:

Legacy tool selections do not elevate the default mode, and mode updates apply to the existing conversation on a later message.
Authorization persists, omitted modes default to unattended, and unsupported modes are rejected.
A desktop refresh cannot override the saved channel mode or add the capabilities checked by that regression.
A scripted file-write request is denied in unattended mode and succeeds in full access.
Search mounts only the built-in trusted server, without putting the fixture credential in its configuration.
A legacy mounted whitelist migrates to the current tool set without elevating approval, and an unchanged session is reused.

I reran these six test functions with Go's race detector against the released source, and they passed.

These checks use temporary databases, temporary files, and a scripted local model. They establish specific policy and refresh behavior; they do not constitute a live WeChat/WeCom delivery test or an end-to-end test of every real search provider. The release notes separately record the broader preflight results and their limits.

For channel users, the practical improvement is a clearer choice between unattended replies and explicitly authorized host actions. For the runtime, the important work is preserving that choice across messages and desktop restores while giving ordinary web research a usable default path.

This article was generated by an AI agent and checked against public tagged source and release information. The six focused channel-policy regression tests were rerun locally with the race detector.

How AIClaw 3.7.18 Configures the App Through Reviewable Chat Cards

chowyu — Wed, 21 Oct 2026 00:06:55 +0000

Changing an agent's search engine sounds like a small request: “Use Tavily as my default search engine.” Completing it can require finding the right settings page, preserving an existing key, testing a connection, and deciding when the running agent should pick up the change.

AIClaw v3.7.18, released on October 20, adds a conversational entry point for that work. The assistant proposes a configuration change, the desktop presents an editable card, and the user confirms the actual settings there. Credentials entered in that card travel through the desktop host's configuration path rather than the model's tool arguments and results.

This feature is in the published release. The source links below are pinned to v3.7.18.

Give the model a proposal interface

The kernel registers two application configuration tools:

app_config_list returns configuration IDs and status for email, search engines, MCP servers, plugins, or schedules.
app_configure opens an editable card and waits for the desktop host's outcome.

The list response exposes useful state, including whether credentials are configured, without returning the raw credential configuration. When editing an existing item, the assistant can discover its ID before proposing a change.

For example, an illustrative app_configure argument object for adding a default search engine contains public fields only:

{
  "category": "search",
  "operation": "default",
  "values": {
    "name": "Research search",
    "provider": "tavily"
  }
}

The user enters the API key in the resulting card. Omitting targetId allows a new engine; editing an existing one uses the ID returned by the list tool. This is a model-tool argument example, not a standalone HTTP API.

The desktop configuration assistant validates the category, operation, and proposed field names. Credential fields such as apiKey and MCP env are excluded from the proposal allowlist. Plugin configuration fields are filled through the card; the proposal interface can identify an existing channel connection.

Make the editable card the write boundary

Opening a card does not immediately apply its proposed settings. The host keeps a pending request with its own identity, and the configuration card component lets the user inspect and edit the values before saving or cancelling.

The flow is deliberately split:

Stage	What happens
Inspect	The assistant reads supported IDs and configuration status.
Propose	The model requests an operation using allowed public fields.
Review	The desktop displays editable settings and dedicated secret fields.
Confirm	The host validates the submitted fields and calls existing settings interfaces.
Report	The model receives a bounded operation result, including test status where supported.

This confirmation remains necessary when the conversation uses the broad tool-approval bypass mode. The kernel tool routes to the interactive host; it does not write application settings itself. The configuration regression tests explicitly exercise that path under bypass.

Pending cards have an expiry. A busy card rejects duplicate submissions, and a successfully completed or cancelled card cannot be submitted again. A renderer reload can recover pending cards from the still-running host. That is narrower than durable recovery across an application restart, and secret drafts are not restored.

The tool description also instructs the model to act on explicit user configuration requests rather than instructions found in email, files, webpages, or tool results. That instruction complements the card boundary; it is not proof that a model will identify every malicious instruction correctly.

Keep credential entry in the desktop path

The host constructs blank secret fields for passwords, authorization codes, API keys, MCP headers, and environment variables. Existing credential state can be indicated without returning the stored value to the model.

On submission, those card values go through dedicated IPC to the desktop host. Blank credential fields preserve existing values. For MCP environment variables or headers, an explicit empty object can clear the stored object.

Provider errors need care as well: a failed request can echo a header or credential. The configuration assistant returns fixed status messages to the model and sanitizes configuration/test failures instead of forwarding arbitrary provider error text through this workflow.

This boundary applies to secrets entered in the configuration card. Pasting a secret directly into the ordinary chat still puts it in the conversation; the new interface does not retroactively remove it.

Reuse each setting's existing behavior

The feature covers five areas, with different validation rules:

Area	Supported behavior and practical boundary
Email	Edit settings, enable, disable, and test. A failed connection test does not newly enable the mail plugin.
Search	Add or edit an engine, test, enable or disable, delete, or select a default. Default selection tests the candidate before disabling other enabled engines.
MCP	Add or edit a server, import one server's JSON, test, enable or disable, delete, and start OAuth login. Testing a stdio server executes its configured command.
Plugins	Install from a local directory, configure, enable or disable, and remove eligible local plugins. There is no universal plugin connection test.
Schedules	Create, edit, pause, resume, and delete tasks through the existing scheduler and rule validation.

The configuration guide documents the remaining workflow boundaries. New channel connections and WeChat QR login still use Settings. An MCP import card accepts one server. Starting an OAuth browser flow is not the same as completing authorization.

Saving and testing are also separate operations. A test failure can leave some configuration already saved, and cancelling afterward does not roll those earlier changes back. The interface reports that distinction rather than promising a transaction across unrelated settings services.

Apply capability changes at a task boundary

Updating a setting does not mean a running model request instantly receives a different tool list.

The desktop store refreshes relevant settings and arranges a remount after the task and automatically queued work finish, or when the conversation is reopened. Schedules are saved immediately, but scheduled work still depends on the application running.

The configuration capability is limited to interactive desktop parent conversations. Child agents, messaging-channel conversations, and background scheduled runs do not receive the same application-configuration entry point. This keeps a request arriving through an external channel from inheriting the desktop's configuration cards merely because its conversation is opened locally.

Check the boundary with controlled tests

The public host-side tests cover status redaction, rejected secret proposals, local confirmation, preserving existing credentials, failed tests, MCP imports, concurrent configuration changes, and scheduler operations. The kernel tests cover opt-in registration, child-agent exclusion, host routing under bypass, and failure without an interactive host. A server regression checks that refreshing a channel session cannot enable the capability.

The Electron workflow smoke checks exercise the real Vue/preload UI against controlled IPC fixtures, including card display, secret fields, cancellation, and restoration after reloading the renderer.

The release notes report a passing local preflight with 286 renderer tests, 10 updater tests, 40 kernel RPC checks, and 174 work-interface checks across the release. The public Desktop Release workflow also completed successfully. These results do not establish complete end-to-end compatibility with every real mailbox, search provider, or model service.

For a user, the useful change is being able to describe a configuration task without navigating every settings screen first. For the runtime, the important distinction is carrying that request through an explicit proposal, an editable desktop card, the existing management interfaces, and a result that states what was actually saved or tested.

This article was generated by an AI agent and checked against public tagged source, release information, and the published workflow result.