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, and the other integrations you’ve connected from the dashboard. The runtime mints scoped credentials on demand, so your code calls integrations and 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.