Claw Deploy
In a nutshell: Claw is the actual execution engine. For day-to-day onboarding, use the "Add Claw" button inside Client. The scripted path exists for batch deployment, automation, or environments where the desktop Client cannot be opened.
When you need another Claw
- Spread AI tasks across your office PC, home Mac Mini, cloud servers, or internal network machines.
- Build a multi-machine AI ops pool for your team.
- Pick the right execution environment per task (GPU / intranet access / specific toolchain).
Recommended: add Claw from inside Client
This is the right path for most people:
- Open Client and go to Claw Management.
- Click the Add Claw button.
- Pick the target platform (macOS / Linux / Windows). The UI generates the full command using your actual Admin domain.
- Follow the on-screen steps. A few seconds later the new Claw appears in the list as online.
- Rename it so you can identify it later in the conversation page.
The entire flow happens in the desktop Client β no need to hand-craft URLs or guess install arguments.
Advanced: scripts and automation
Common scenarios for the scripted path: batch onboarding across many hosts, CI/CD pipelines installing Claw automatically, or remote servers without a desktop session. Commands are served same-origin from your Admin:
bashcurl -fsSL https://myclaws.weid.fun/install/claw.sh | bash
powershellirm https://myclaws.weid.fun/install/claw.ps1 | iex
The script downloads the runtime, installs it to ~/.myclaws/claw/, registers a background service, and connects to Admin automatically. The domain in the URL must match the domain you use for Admin β cross-domain installation will fail.
Install path and service identity
- All Claws are installed to
~/.myclaws/claw/. - Service identity uses a generic identity:
io.myclaws.claw/myclaws-claw/MyClawsClaw. - This means only one active Claw can occupy the canonical service identity on a given host (single-active arbitration constraint).
Four control semantics buckets
client-managed: directly controlled by the current desktop Client.service-managed: continuously maintained by the host OS service mechanism.legacy_unmanaged: historically connected but not under unified control.unknown_shared: visible but ownership cannot be determined.
The four buckets are mutually exclusive; platform logic assigns each Claw to the appropriate bucket.
Auto-update and version switching
After starting, Claw periodically reports its version to Admin. When a new version is available, an Update button appears on the management page. The update process downloads the new runtime, stops the old one, starts the new one, and preserves the service identity.
Direct-connect address across Admins
In addition to Admin relay, Claw also supports direct-connect mode. The desktop Client can view, set, modify, and clear the direct-connect address. New sessions use the new address immediately; existing sessions prompt the user to reconnect manually.
Uninstalling and log access
- In Claw Management, select the target Claw β Uninstall.
- The system stops the service, cleans up the runtime directory, and revokes the Admin registration.
- Conversations and Skills in
~/.myclaws/claw/data/are not deleted automatically (to prevent accidental loss). - Each Claw provides a log viewer (collected by service identity, including process stderr/stdout).
Single-active constraint and cross-host migration
Single-active constraint
Two Claws cannot both hold the canonical service identity on the same host. Startup arbitration selects one active identity and stops the old one.
Uninstalling does not delete user data
Data remains in ~/.myclaws/claw/data/. Delete it manually for a full cleanup.
High-risk migrations require a backup
Changing the canonical path or migrating across hosts is high-risk. Back up your data first and confirm a rollback path.