How AIClaw 3.7.18 Configures the App Through Reviewable Chat Cards

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.