AIClaw 3.7.35 如何區分手動 Shell 命令與智能體執行

A chat reply can contain a useful command without asking the agent to execute it. That leaves a small but awkward handoff: copy the command, open a terminal, find the right directory, and then return to the conversation to explain the result.

AIClaw 3.7.35 adds an explicit run action beside recognized commands. The command runs in the conversation's working directory, streams output into the interface, and exposes a stop action. This behavior is in the published release. All implementation links below are pinned to that tag.

The important boundary is who starts the process. This is a user-operated system-shell path, separate from the agent's sandbox and approval flow.

Recognize a command without turning every code block into a button

Consider a reply containing:

python3 sum1to100.py

The script name is a file, but the whole line is an instruction to an interpreter. Treating it as a generated-file card loses that distinction.

The Markdown renderer classifies shell fences and recognized command lines separately from ordinary source code. It also identifies command-like inline code before applying file-reference rendering. A script reference can still open as a file; a command invoking that script retains its command text.

Recognition is heuristic. It uses language labels and recognizable command forms rather than proving what arbitrary text will do. The release also keeps terminal transcripts containing output from becoming executable command actions. None of this classification establishes that a command is safe.

Make execution an explicit action

The command action component starts a run from its button handler and rejects events whose isTrusted flag is false. That prevents a plain synthetic click from using that handler to start a process. It is a UI safeguard, not an operating-system sandbox or a complete security boundary.

The control identifies the action as execution in the system shell outside the sandbox. Clicking it authorizes that manual run; the app does not send the same command back through the agent's approval dialog.

The main-process handler looks up the requested conversation instead of accepting an arbitrary working directory from the renderer. It uses the stored directory, or the home directory when none is set. It also checks whether the window changed while asynchronous setup was in progress, so a pending start is rejected after a reload or navigation changes its generation.

Keep process behavior visible and bounded

The command runner invokes the configured system shell on Unix, falling back to /bin/sh. Windows uses the command processor from ComSpec or COMSPEC, with cmd.exe as the fallback. It passes the original command through that shell rather than splitting it into a guessed argument list.

Standard output and standard error are decoded as UTF-8 and streamed into the run display. The UI receives an exit code, a stopped flag, or a startup error. Both streams feed the same output display; this is not a full terminal emulator.

The runner permits at most 20 concurrent jobs and caps forwarded output at 1,000,000 JavaScript string code units per job. It continues draining the pipes after the cap and emits a truncation notice. The cap limits retained display output; it does not stop the underlying command or limit its filesystem effects.

Standard input is closed immediately. Commands that need an interactive prompt belong in a terminal.

Tie cleanup to the window, not the selected conversation

Run state includes both a run ID and a conversation ID. Switching chats does not terminate the process: the user can return to inspect output or stop it. Stop requests are scoped to the owning conversation.

On Unix, stop targets the process group and escalates from termination to a kill signal after three seconds if needed. Windows uses taskkill with tree termination, with a child-process fallback. Window reload, closure, and application shutdown also trigger cleanup. This describes the implemented process-management strategy, not a guarantee that every deliberately detached descendant can be contained.

Renderer run state is held in memory. These results are not added to durable conversation history, and reloading the window does not restore a terminal session.

What the verification establishes

For this article, I ran the eight tag-pinned command-runner tests in an isolated temporary directory on macOS; all eight passed. They cover working directories, streamed output, nonzero exits, invalid requests, session-scoped stopping, reload and shutdown cleanup, shell argument construction, system execution, and output truncation.

The release notes separately report a complete local make check, including 335 frontend tests and 316 desktop workflow checks. I did not rerun that complete suite or a Windows desktop session for this article. Assertions about Windows shell arguments are not a substitute for a real Windows end-to-end run.

The feature removes a copy-and-paste handoff while keeping manual execution visible. It is appropriate when the user has reviewed a command and wants to run it locally. It does not make the command read-only, sandboxed, interactive, or automatically recoverable.