#Multiple openclaw agents each with their own gmail account accessed via gog

1 messages · Page 1 of 1 (latest)

sick copper
#

Goal: Run 7 openclaw agents on one self-hosted Mac mini. Each has its own persona, files, and Gmail account accessed via gog.

Hard requirement: Strict credential isolation. Agent A must not be able to read Agent B's Gmail, e.g. by shelling out to gog --account agentB@gmail.com gmail search .... Hostile-agent / prompt-injection threat model.

Options as I see them

  1. Single gateway, multi-agent routing only. Per-agent agentDir, workspace, auth profiles. But as I read it, this doesn't isolate gog — it stores OAuth refresh tokens in the macOS Keychain (or ~/Library/Application Support/gogcli), which is per-unix-user, not per-agent. All 7 agents run as the same gateway process, so any can read any other's tokens. Rules this out for me.
  2. Single gateway + per-agent sandbox (mode: "all", scope: "agent"), gog installed in the sandbox image and authenticated inside each per-agent container.
  3. 7 openclaw docker containers, one per agent, on OrbStack or Docker Desktop. Drop multi-agent — each container is one agent, with its own filesystem, gog install, and file-based keyring volume. Currently leaning this way.
  4. Same as #3 but with 7 full Linux VMs.

Where I might be wrong

  • Is it right that per-agent auth-profiles.json only holds openclaw's auth (model providers, channel tokens), and has nothing to do with gog's OAuth tokens? That's the crux of why I think #1 doesn't work.
  • Anyone actually running 7+ gateway VMs on a Mac mini (option 4)?

Main concern with any Docker-based option: tool persistence. If an agent does an ad-hoc brew install or pip install during a task, it's gone next rebuild. Patterns I can think of:

  • Bake common tools into the image, rebuild when needed.
  • Persistent volume mounted at /usr/local or wherever installs land (feels fragile).
  • Persistent ~/.local/bin volume + pip install --user (Python-only).
  • Just accept it and have the agent reinstall.

Any ideas?

cursive nexusBOT
#

My take: your reasoning about #1 is basically right. OpenClaw’s per-agent auth-profiles.json isolates OpenClaw/provider auth per agentDir, but it does not automatically isolate an external CLI’s credential store. gog stores its own refresh tokens in a keyring/backend, and it supports selecting accounts with --account / GOG_ACCOUNT, so same Unix user + same reachable keyring = not a hostile-agent boundary. (docs.openclaw.ai)

For your threat model I’d rank them:

  1. Best practical choice: #3 — one OpenClaw gateway container per agent.
    Each container gets only that agent’s workspace, .openclaw, gog config/keyring volume, Gmail OAuth client/token, and channel account. Don’t mount shared ~/.config, macOS Keychain, host home, or Docker socket into agent-reachable tool environments. Docker isn’t VM-grade isolation, but it matches “one agent = one credential principal” much better than multi-agent routing alone.

  2. Acceptable middle ground: #2 — single gateway + sandbox.mode: "all", scope: "agent".
    This can work if gog is authenticated inside each per-agent sandbox, with file keyring and per-agent env/volume. But the Gateway remains the trusted control plane, and OpenClaw’s own docs call sandboxing blast-radius reduction rather than a perfect boundary. Also make sure tools.elevated / host exec / host browser control aren’t escape hatches. (docs.openclaw.ai)

  3. #4 VMs: strongest isolation, highest ops overhead. I don’t have a verified “7 gateway VMs on a Mac mini” datapoint; worth asking in #users-helping-users for lived experience.

For persistence: don’t rely on ad-hoc brew install as state. I’d use:

  • custom base image with gog, Python, node, jq, etc.
  • per-agent persistent volume only for:
    • /home/<user>/.openclaw
OpenClaw
OAuth - OpenClaw
#
  • workspace
    • ~/.config/gogcli / file keyring
    • maybe ~/.local or /opt/agent-tools
  • use pipx/uv tool into that per-agent tools volume if agents need self-installed Python tools
  • avoid mounting /usr/local wholesale

OpenClaw sandbox setupCommand runs once when the sandbox container is created, but package installs need network, writable root, and often root; for repeatability I’d bake common tools into the image instead. Docker OpenClaw deployments also persist config/workspace via mounted dirs, so do that per agent, not shared. (docs.openclaw.ai)

Tiny config-shape sketch for #2-ish:

{
  agents: {
    list: [
      {
        id: "agent-a",
# 
        workspace: "/srv/openclaw/agent-a/workspace",
        sandbox: {
          mode: "all",
          scope: "agent",
          workspaceAccess: "none",
          docker: {
            image: "my-openclaw-gog-sandbox:latest",
            network: "bridge",
            env: {
              GOG_ACCOUNT: "agent-a@gmail.com",
              GOG_KEYRING_BACKEND: "file"
            },
            binds: [
              "/srv/openclaw/agent-a/gogcli:/home/node/.config/gogcli:rw"
            ]
# 
          }
        }
      }
    ]
  }
}

But if strict isolation is the hard requirement, I’d still choose #3 over this. Also: if you implement it, sanity-check with openclaw --version and openclaw sandbox explain so the effective sandbox/tool policy matches what you think it is.

sick copper
#

If I go with one openclaw container gateway per agent, then which tools might I want to bake into the docker image (I mean ones that openclaw comes with or can install during setup, plus ones like ffmpeg that many users install)?

cursive nexusBOT
#

I’d split this into gateway image baseline vs optional tool image.

For your “one container = one agent” setup, I’d bake:

Baseline essentials

  • ca-certificates, curl, wget
  • git, openssh-client
  • jq, ripgrep, unzip, file
  • procps, lsof, hostname
  • python3, python3-pip, ideally pipx/uv
  • Node/pnpm are already part of the OpenClaw image path, but verify in your built image

Strongly useful for OpenClaw/media

  • ffmpeg + ffprobe — Discord/WhatsApp/voice/TTS/audio conversion often wants these
  • imagemagick maybe, if agents manipulate images
  • poppler-utils if they inspect PDFs outside OpenClaw’s PDF tool
#

Browser automation

  • Build with OpenClaw’s browser option / install Chromium+Playwright deps if you want in-container browser automation.
  • For Docker, docs recommend using the bundled Playwright CLI path, not npx playwright.

Your Gmail stack

  • gog
  • whatever keyring/file-backend deps gog needs
  • optionally gcloud only if you’re doing Gmail Pub/Sub/watch setup

Coding/build tools, if agents code

  • build-essential, pkg-config
  • make, cmake
  • go, rustc, cargo only if needed
  • sqlite3
  • shellcheck

Maybe, per use-case

#
  • pandoc
  • yt-dlp
  • rclone
  • awscli / gh / gcloud — only if that agent genuinely needs them, because these become extra credential surfaces.

I would not bake/mount the Docker socket or Docker CLI for hostile-agent isolation unless you really know why. In OpenClaw Docker deployments, Docker CLI/socket is needed for Docker-backed sandboxing, but the socket is basically a host escape hatch.

For persistence, my preferred pattern:

Image:
  /usr/local/bin/gog
  apt tools
  ffmpeg
  browser deps
  common language runtimes
sick copper
#

OK this makes sense. But I also want each agent to have a chrome browser logged in to their own Google account. If I were openclaw on a mac mini, this would be easy, as I can just open the browser and log in myself. But if I run agents inside docker containers how can I have them log in to chrome with my google account?

cursive nexusBOT
#

Yep — Docker can still work. You just need a per-agent remote browser UI, not the Mac’s shared Chrome.

For your threat model, I’d do one of these:

Best fit: one browser profile/container per agent

Run a Chromium/noVNC/CDP browser beside each agent container, with its own persistent volume:

  • agent-a-openclaw container
  • agent-a-chrome container
  • agent-a-chrome-profile volume
  • noVNC exposed only on 127.0.0.1 or behind Tailscale
  • CDP reachable only from that agent’s OpenClaw container

Then you open the noVNC URL, manually log into Google, handle 2FA, and the cookies stay in that agent’s browser volume.

If using OpenClaw sandbox browser

OpenClaw’s Docker sandbox browser already supports Chromium + CDP + noVNC. Enable sandbox browser per agent, keep scope: "agent", and use a separate persistent bind/volume for each agent’s browser data, e.g. conceptually:

# 
{
  agents: {
    list: [
      {
        id: "agent-a",
        sandbox: {
          mode: "all",
          scope: "agent",
          browser: {
            enabled: true,
            headless: false,
            binds: [
              "/host/openclaw/agent-a/chrome:/home/sandbox/.chrome:rw"
            ]
          }
#
  • Don’t use profile="user" / host Chrome / allowHostControl if strict isolation is the goal. That punches through the container boundary.
  • Don’t mount your Mac Chrome profile into containers. It’s brittle, likely tied to macOS Keychain, and violates isolation.
  • Don’t give the agent your Google password. Log in yourself through noVNC.
  • Prefer one Google account per agent. If all 7 use the same Google account, the browser isolation is mostly cosmetic.
  • Persist the Chrome profile volume; otherwise a rebuild/recreate can wipe the login.

So: Docker is fine, but treat the browser session as another per-agent credential store, just like gog tokens.

sick copper
#

If I run openclaw inside docker what browser does it get by default?

cursive nexusBOT
#

Short version: it does not get your Mac Chrome.

If OpenClaw itself runs inside Docker, the default browser profile is still named openclaw, but it means:

  • OpenClaw tries to control a Chromium-based browser inside the container
  • On Linux/container environments it will usually run headless
  • The default Docker image is security/minimal, so you may need to install/bake Chromium first
  • It will not see your host Mac browser, cookies, Keychain, or Google login

For your setup there are two separate concepts:

  1. Gateway container browser
    Browser lives inside that OpenClaw container. Good if each agent is a whole separate container.

  2. Sandbox browser
    Separate Chromium + CDP + noVNC browser container for sandboxed agents. This is probably what you want if doing single gateway + per-agent sandbox. It uses the sandbox browser image, not your Mac Chrome.