If you are about to invite an autonomous agent into your inbox and file system, the first question on your mind should be: What is the blast radius if it goes rogue? This guide walks through the safest starting point — running OpenClaw with read-only permissions. We will cover the exact OAuth scopes, the ClawCloud UI toggles, and the local config.yaml needed to ensure the agent can read email, calendars, and files but cannot modify or delete anything. You will still get value — daily briefings, summaries, research — while sleeping well at night.

Why defaulting to read-only matters

OpenClaw’s super-power is that it plugs into 800+ APIs through Composio. That is also its biggest foot-gun. A single YAML typo or a hallucinated shell command can wipe a GitHub repo, email everyone in your address book, or schedule meetings at 3 AM. Starting read-only limits damage to embarrassment at worst.

You are in good company. A quick scan of the GitHub discussions shows that most orgs run the first week read-only, collect logs, then progressively unlock writes. The pattern works, so we are documenting it here.

The minimum viable read-only scope set

Below are the scopes I actually use in production for my personal agent. They map one-to-one to the buttons you will see in ClawCloud and the OAuth requests when self-hosting.

  • Gmail: https://www.googleapis.com/auth/gmail.readonly
  • Google Calendar: https://www.googleapis.com/auth/calendar.readonly
  • Google Drive: https://www.googleapis.com/auth/drive.readonly
  • GitHub (optional): repo:status and read:user
  • Filesystem: mounted as a Docker volume with ro flag

No write scopes, no push permissions. If you see the word modify, compose, or write in the scope description, decline it for now.

Step-by-step: Provisioning a read-only agent on ClawCloud

1 — Create the agent (60 seconds)

Sign in to ClawCloud → New Agent. Pick a name (briefing-bot-ro). Select the Node 22 runtime. Hit Create.

2 — Toggle Safe Mode

Immediately after creation, go to Settings → Permissions. Flip the global Safe Mode switch. Under the hood this sets ALLOW_WRITES=false inside the container. It also hides write-capable tools from the agent’s tool inventory.

3 — Connect services but pick read-only scopes

ClawCloud walks you through OAuth for Gmail, Calendar, Drive, and any other integration you enable. On the OAuth consent screen, Google shows separate check-boxes for modify vs read. Uncheck everything except the read equivalents. If you miss a checkbox, you can revoke and redo the grant from Settings → Integrations.

4 — Verify from the agent shell

OpenClaw starts an ephemeral shell you can access from the web UI. Run:

openclaw-tool list --verbose | grep "write"

The list should be empty. If you see gmail.send or calendar.createEvent, something is mis-configured.

5 — Save a safety baseline snapshot

From the Snapshots tab, capture the container state. In worst case you can roll back in one click.

Local install: read-only config with environment variables

If you self-host, the pattern is similar but you control everything in code. Assuming Node 22.3 and Docker 26.1.

1 — Install and scaffold

# Node 22+ is mandatory nvm install 22 npm i -g openclaw@latest openclaw init briefing-bot-ro

2 — Harden the Dockerfile

Inside Dockerfile, mount the host data directory read-only:

# Snippet VOLUME ["/data:ro"]

This prevents even a superuser inside the container from altering host files.

3 — Pin the scopes in config.yaml

# config.yaml permissions: gmail: scopes: - https://www.googleapis.com/auth/gmail.readonly calendar: scopes: - https://www.googleapis.com/auth/calendar.readonly drive: scopes: - https://www.googleapis.com/auth/drive.readonly github: scopes: - repo:status - read:user # global flag allowWrites: false

The daemon validates this on boot. If someone pushes a config with allowWrites: true the process exits non-zero and Kubernetes will refuse the deployment (tested with k3s v1.30).

4 — Environment safeguard

# .env OPENCLAW_ALLOW_WRITES=false

Why both YAML and .env? Defense-in-depth. In CI sometimes we swap configs; the environment flag is a final guardrail.

5 — Smoke test

openclaw start --dry-run # Expected output # ✔ Gmail (readonly) # ✔ Calendar (readonly) # ✔ Drive (readonly) # ✖ GitHub write scopes missing (intentional)

What you can actually do without write access

Read-only sounds limiting, but in practice it covers 80 % of my daily use-cases.

  • Morning briefing: Summarise all unread email tagged @today, upcoming meetings, and PRs assigned to me. The agent posts a Markdown digest in Slack.
  • Context while coding: Ask “what did Alice say about the pagination bug?” and get the relevant email snippet inline in VS Code (via the OpenClaw VSCode extension v0.7).
  • Research assistant: Feed it PDFs from /data/research/2024-q2/*.pdf (mounted read-only). It can extract text and answer questions but cannot alter the originals.
  • Calendar preview: “Do I have any 30-minute slot on Thursday?” — it scans events and suggests times, but leaves scheduling to me.
  • Code review summary: With repo:status only, the agent cannot merge, but it can read diff stats and draft a review comment I can copy-paste.

The common theme: the agent prepares information; I decide the next action.

Threat model and remaining risks

Read-only is not a silver bullet. Consider:

  • Confidentiality: The agent still sees your private data. If it is compromised, data exfiltration is possible.
  • Indirect writes: A clever prompt could instruct you, the human, to perform a destructive action. Social engineering is out of scope for technical permissions.
  • Cached embeddings: OpenClaw stores vector embeddings in a local SQLite DB by default. Those embeddings contain chunks of your documents. The DB lives inside /var/lib/openclaw. If you worry, mount that directory on an encrypted volume.

When and how to turn on writes safely

Eventually you’ll want the bot to draft emails, schedule meetings, or open GitHub issues. My rule of thumb: flip permissions only after the agent has suggested the action at least five times without errors. If its suggestions are sane, chances are the automated version will be fine.

  1. Grant a single write scope (e.g. gmail.compose). Leave others read-only.
  2. Add user confirmation middleware: in agent.ts hook into the beforeExecute event: agent.on('beforeExecute', async (toolCall) => { if (toolCall.permission === 'write') { return await ui.promptUser(`Allow ${toolCall.name}?`); } });
  3. Audit logs: enable LOG_LEVEL=debug and ship logs to Loki. On ClawCloud, toggle Retention → 30 days.
  4. Fallback plan: keep the snapshot from the read-only era. If things go south, restore.

Checklist & next steps

  • [ ] Safe Mode on (ALLOW_WRITES=false)
  • [ ] OAuth scopes limited to *.readonly
  • [ ] Docker volumes mounted with :ro
  • [ ] Tool list inspected — no write tools present
  • [ ] Snapshot saved
  • [ ] Logs streaming to your SIEM

Once those boxes are ticked, fire up the agent, ask it for tomorrow’s calendar digest, and watch it work without writing a single byte back. When you start missing automated replies or calendar invites, you will know it is time to graduate to selective write permissions.