AIClaw 3.7.42 如何在首次工具呼叫前同步桌面輔助程式

A desktop application's main process and its native automation helper have different lifecycles. Updating the main app does not, by itself, refresh a helper copied into a user's home directory. If synchronization only happens when an agent first invokes a desktop tool, a newly installed application can appear to have no independent helper at all.

AIClaw 3.7.42 moves that preparation earlier: every macOS startup starts a background synchronization of the bundled Computer Use application into a stable, user-owned location. This is released behavior. The source links below are pinned to that release; later development is outside this article's scope.

Prepare the helper without starting a desktop session

The startup hook calls the installer after creating the main window and menu. It does not await synchronization before continuing application startup. Completion and failure are written to the application log.

The destination is:

~/.aiclaw/computer-use/AIClaw Computer Use.app

The helper is supplied by the application package. This step does not download another driver, launch the helper, or request macOS permissions. Synchronization also runs when an application update is followed by a restart.

Tool startup retains its own installation call. An unsuccessful background attempt therefore does not permanently disable preparation: a later desktop-tool invocation can try again. That is a retry of installation, not a replay of user input.

Reuse an identical bundle

The installer first resolves the bundled source and checks the destination directory. It must be owned by the current user, must not be a symbolic link, and must not be writable by other users.

It then acquires an installation lock. Competing hosts wait for the same lock instead of copying over each other's work; an exhausted wait produces an explicit busy error.

After verifying the source signature, the code computes a SHA-256 identity from two files: the native executable and the bundle's signed resource manifest, Contents/_CodeSignature/CodeResources. Including the resource manifest matters: a resource-only update must still synchronize even if the executable bytes have not changed.

If the installed identity matches and its signature verifies, the installer returns the existing path. It does not copy or re-sign an identical application on every startup.

Verify the candidate before replacing the installed copy

For a changed or invalid owned copy, the sequence is:

verify bundled source
  → copy into a temporary sibling directory
  → verify the staged signature
  → compare the staged identity with the source
  → move the previous app aside, if present
  → rename the candidate into the stable destination

The candidate is checked before the old application is moved. If the final candidate rename fails, the installer attempts to restore the previous application. Staging cleanup and lock release run in a finally block.

These are same-filesystem rename operations, not a claim that the whole multi-step replacement is a crash-proof transaction. The useful boundary is narrower: signature or identity failure during candidate preparation leaves the installed generation in place, and the normal final-rename failure path includes restoration.

A stable path does not settle macOS permission identity

The release notes explicitly state that this helper still uses an ad-hoc signature. An upgrade may require granting Accessibility and Screen Recording again. Keeping the filesystem path stable does not establish a persistent Developer ID identity or guarantee that macOS will retain earlier grants.

Those permissions belong to the independent helper. Copying it is separate from launching it, and launching it is separate from authorization. None of those steps proves that an agent successfully completed a desktop task.

The startup hook in this release is macOS-only. Windows and Linux behavior is outside this article’s scope. It also does not claim that the helper is installed as a separate top-level application in /Applications.

What the tests establish

For this article, I downloaded the public, tag-pinned installer and its test suite into an isolated temporary directory on macOS and ran the suite with Node's test runner. All four tests passed.

They cover reuse of an identical installation, replacement by a new generation, resource-only updates, preservation of an existing installation after a staged signature rejection, subsequent retry, concurrent callers, and refusal of linked destinations.

These are filesystem fixtures with an injected signature verifier. They exercise the installer control flow; they do not execute the production codesign verifier, launch the packaged helper, or verify permission retention after an actual application upgrade. I did not run a packaged update or a desktop automation task for this article.

The improvement is specific but useful: opening AIClaw now prepares its bundled helper before the first desktop-tool request, while retaining explicit verification, reuse, and failure boundaries.