Runtime

Every Clawnify org gets a dedicated, managed runtime. This is where your agent lives, where the browser opens, where clawnify.execute actually runs your code, and where connected integrations, channels, and file system are pre-wired.

What’s in the runtime

  • The agent. OpenClaw (default) or any other supported runtime. Speaks to your channels (WhatsApp / Telegram / Slack / email / voice) and to the browser.
  • Connected integrations. Google Workspace, Microsoft 365, Composio, and other integrations you’ve connected from the dashboard. The runtime mints scoped credentials on demand — your code calls integrations, never handles the underlying tokens.
  • Pre-installed tooling. Node.js, a real browser, a virtual display for browser automation.
  • File system + storage. Files written by the agent or by clawnify.execute persist in the agent’s workspace and replicate to managed storage. Recoverable, exportable.
  • Channel ingress. Inbound messages (WhatsApp / Telegram / email / Slack) route into the agent’s session here.

Isolation

One org → one runtime. No cross-org compute, no shared filesystem, no shared credentials. A runaway loop in one customer’s clawnify.execute can’t reach another customer.

Within the runtime, code-mode runs (clawnify.execute) get their own resource bounds — capped CPU, memory, and process count per call — so a misbehaving snippet can’t take down the agent itself.

Where it lives

On managed infrastructure in your selected region (EU or US). Provisioned automatically when you onboard; you don’t manage the underlying compute.

What the runtime is NOT

  • It’s not your laptop. Code-mode runs on the managed runtime, not in your terminal.
  • It’s not a sandbox per-call. It’s a persistent environment. State you write to the file system stays across calls. Use this to your advantage; don’t expect ephemeral semantics.
  • It’s not multi-tenant. Other orgs don’t share anything with yours.