Setup

Guided first-run setup for a stable Msty Claw workspace

Msty Claw is Msty's desktop agent app for practical, end-to-end execution: local or cloud model use, controlled automation, repeatable playbooks, and channel-integrated workflows when you need them. It is designed to move from "single prompt help" to reliable day-to-day operations without losing visibility or control.

This setup guide is written for a strong first run. By the end, you should have one bot running in a controlled workspace, a model provider configured correctly, and baseline security in place before any broader rollout.

Quick setup sequence

Install Claw
Connect a model provider
Set default working style
Create and validate one bot
Apply security baseline
Add tools only as needed
Add channels and Cloud Sync only after local flow is stable

Install

Download Msty Claw from msty.ai/claw and install it on your machine.

Msty Claw is compatible with:

macOS
Windows
Linux

Start by connecting a model provider

Go to Settings > Providers and configure at least one provider. This is the foundation for every chat, bot run, playbook execution, and task.

If you are working with cloud models, verify credentials and endpoint details before moving on. If you are using a local runtime, confirm the service is reachable and that at least one model can be selected. It is worth spending an extra minute here because most "setup issues" later are actually provider connectivity problems.

Minimum provider checks:

You can select at least one model
A test chat response succeeds
Provider latency and errors look reasonable for your workload

For full provider setup and model routing guidance, see Model Providers. For local runtime setup details, see Managed Services.

Set your default working style early

Before creating bots, set your app default in Settings > General. Working style affects how Claw plans, explains, and executes. Choosing this up front gives you consistent behavior across new chats and bots, which makes validation easier.

If you are unsure, choose a balanced default and then override style per bot only when there is a clear reason.

Common starting point:

App default: Balanced
Override to Careful for higher-risk bots

For style behavior and selection patterns, see Working Styles.

Create one bot and validate it in a narrow scope

Go to Settings > Bots and create a single bot for your first validation run. Give it a small, intentional scope: one workspace, one runtime mode, and local-only routing unless you already need channel delivery.

When selecting runtime, use host mode for fast iteration and container mode when isolation matters more than speed. If you choose container mode, make sure Docker or Podman is already available on your machine.

At this stage, avoid adding too many advanced options. The objective is a stable first run you can trust, not a fully optimized bot profile.

For your first bot, keep scope intentionally narrow:

One workspace
One runtime mode
Local only routing for initial validation

For deeper bot configuration and lifecycle guidance, see Bots.

Apply your security baseline before adding integrations

Open Settings > Security and configure sender groups, allowed folders, blocked patterns, and a Network Guard preset. This is where you define operational boundaries for bot behavior.

A practical baseline is to limit workspace access to the project paths the bot actually needs and keep network policy conservative until you confirm your workflows. Security settings are much easier to tune before channels and external tools are heavily used.

Baseline controls to set before wider rollout:

Sender groups
Allowed folders
Blocked patterns
Network Guard preset

For full hardening guidance, see Security.

Add tools only for immediate workflow needs

In Settings > Tools, configure MCP servers and web search only when they support a concrete task. Starting with a minimal tool surface reduces noise and makes troubleshooting simpler.

If you add tools now, test each one in isolation once so you can separate tool-specific issues from bot or provider issues.

Add channels and Cloud Sync when your local flow is stable

Channels in Settings > Channels and Cloud Sync in Settings > Cloud Sync are best treated as phase-two setup. They are optional for local bot operation and should come after core execution is already reliable.

Connect channels only if you need remote routing through Discord, Telegram, or WhatsApp. Enable Cloud Sync only when device continuity is required and your team has a plan for recovery key handling.

Phase-two rollout criteria:

Core local bot run is stable
Security baseline is already configured
You have explicit operational need for remote routing or cross-device continuity

For implementation details, see Channels and Cloud Sync.

Run a first end-to-end validation

Now run one safe, representative task through your first bot. Use a real workspace action that is low risk, then confirm output quality, approval behavior, and runtime execution all match your expectations.

If you enabled tools or channels, run one controlled validation per integration path. Avoid bulk automation until each path is verified individually.

Minimum done-state checklist

One provider connected and one model selectable
One bot created and runnable in intended workspace
Security baseline applied (sender, folder, network)
Optional tools/channels validated one path at a time

If setup fails, debug in this order

First check provider connectivity, then workspace permissions, then runtime availability. That order resolves the majority of first-run failures quickly.

If container runs fail, verify Docker/Podman status before changing bot prompts or model settings.

Overview

How Msty Claw works and where to start

Security

Configure sender controls, folder policy, and network guard in Msty Claw