Deployment, permissions, and multi-model guidance

The Desktop app is optimized for immediate operational use. It provides visual installation and upgrades, a configuration interface, common integrations, and safer defaults so non-developers can become productive quickly. The open-source core is the extensible runtime layer. It focuses on plugins, skills, model and tool abstractions, task orchestration, and memory, making it more suitable for custom development. One emphasizes operational speed. The other emphasizes extensibility and deeper control.

Yes. OpenClaw is best operated with layered controls rather than a single warning step. Command-level authorization can separate read, write, and execute privileges and block dangerous actions through allowlists or denylists. Directory controls can confine readable and writable paths to a designated workspace or sandbox. Side-effect actions such as deletion, payments, email delivery, or message posting can require explicit confirmation and leave an audit trail. Stronger isolation can be added through dedicated accounts, containers, virtual machines, and outbound network restrictions. The result is a more fault-tolerant operating boundary even when a model behaves imperfectly.

Yes. Multiple models and providers are supported, and the strongest operating pattern is to treat them as a shared capability pool. Long-form writing, coding, summarization, batch processing, and latency-sensitive interactions can each route to different models according to task fit. Higher-cost models can be reserved for decisive steps, while lower-cost models handle screening, outlining, or large-scale background work. Fallback routing also matters. If one provider becomes unstable or rate-limited, another can take over without stopping the workflow. Centralized management of providers, models, API keys, and quotas helps reduce cost while avoiding unnecessary lock-in.

This is a bilingual static-site template used to preview layout, interaction patterns, and information structure. Download links, integration references, testimonials, and supporting text can be replaced or extended to match the actual product or project. Before public release, brand information, download destinations, documentation, community links, and security-boundary statements should be validated so the site reflects the real operating environment and release channels.

Windows deployments generally work best with a signed installer or a portable ZIP build. Installers are convenient for standard users because they integrate with shortcuts, uninstall flows, and common system conventions. Portable builds are useful for workspace-based operation and controlled movement between environments. When startup fails, the most common checks include antivirus quarantine, missing runtime dependencies, policy restrictions, long or permission-protected paths, locked files, and initialization delays caused by proxy settings. Application logs and Windows Event Viewer usually provide the clearest direction for diagnosis.

Linux deployments are usually strongest when treated as services. On a single machine, systemd under a dedicated user is often the most predictable approach. On servers, Docker or Podman generally provides clearer permission boundaries and better reproducibility. Least-privilege operation remains important in every case: restrict writable paths, separate service accounts, constrain outbound networking, and avoid exposing internal ports directly to the public internet. Reverse proxies, authentication gateways, health checks, and restart policies strengthen both security and operational continuity.