Skip to main content
OpenClaw makes its LLM and tool calls in-process, so it works cleanly with transparent egress. Wrap the gateway with sesame launch and every brokered call — its model provider, Stripe, anything you’ve configured — is injected by the broker after your approval. OpenClaw itself stores only placeholders.
This guide uses the cloud broker at getsesame.dev, so you never run your own broker or hold your own keys. Running your own broker? See Self-Host — the only difference is sesame login --broker-url <your-url>.
Human-in-the-loop. Several steps hand off to a person in the getsesame.dev dashboard: approving the device (step 2), adding secrets (step 3), and approving calls (steps 4 and 6). The CLI commands block and wait for these. If you’re an agent running this guide, stop at each hand-off and ask the user to complete the dashboard action before continuing — don’t assume it succeeded.

​
Where is your OpenClaw running?

Hostinger (managed template)

OpenClaw deployed from Hostinger’s VPS template runs inside a Docker container with its own quirks — follow the Hostinger guide instead. More providers coming.

Any other host (self-managed)

Your own VPS, bare metal, or laptop where you run openclaw gateway run yourself — continue below from Step 0.

​
Step 0: get shell access to the OpenClaw host

Every command here (sesame login, sesame launch, …) runs in a terminal on the machine where the OpenClaw gateway runs — not in the OpenClaw UI. The Control UI talks to the gateway; it doesn’t give you a shell. So before anything else you need shell/SSH access to that host, and that host must be able to reach the broker at getsesame.dev.
If you’re an agent running this onboarding and you don’t already have a shell on the OpenClaw host, establish that first — do not skip ahead. Work out how to get in:
  1. Look locally. Search the working directory and any setup notes for connection details: ~/.ssh/config, *.pem / id_* private keys, README/deploy docs, docker-compose.yml, Terraform/Ansible files, or a cloud-console / hosting-dashboard link.
  2. Verify it works and reaches the broker:
    Seeing shell-ok plus a healthy response confirms both the login and that the box can talk to Sesame.
  3. If you can’t find a way in, ask the user for the host address, SSH user, and key — or how they normally reach the box (cloud console, provider web terminal, etc.). A UI-only user often won’t know offhand; help them locate it.
  4. Only once you have a working shell that can reach getsesame.dev should you continue.

​
Prerequisites

  • Shell/SSH access to the host running the OpenClaw gateway (see Step 0 — the commands below do not run in the OpenClaw UI).
  • An OpenClaw instance you can run (openclaw gateway run).
  • Node 22.19+ (OpenClaw’s requirement).
  • A Sesame account at getsesame.dev.

​
1. Install the Sesame CLI + edge proxy

​
2. Register your agent

sesame login prints a claim URL and then blocks, waiting for approval.
You, in the browser: open the claim URL, sign in to getsesame.dev, and approve the device. The command waits until you approve (it times out after ~15 minutes) and then prints Agent approved. Don’t move on until you see that.

​
3. Store your API keys in Sesame

In the dashboard (Secrets → Add), add one secret per provider your agent uses — for example: The dashboard presets fill in the correct injection mode. Your real key is stored in Sesame’s vault — OpenClaw never receives it.
You, in the browser — this is a manual dashboard step, there’s no CLI command. Add a secret for each provider your agent will call before you launch it.

​
4. Replace OpenClaw’s real keys with dummies

So OpenClaw holds nothing real, overwrite its stored provider key with a placeholder using OpenClaw’s own onboarding — run it under sesame launch so the key-validation call is brokered (your real key is injected) while OpenClaw stores only the dummy. For example, to set a placeholder for the provider your agent uses:
Running under sesame launch means OpenClaw’s key-validation call is brokered — so it raises an approval in the dashboard and waits. Approve it (Approvals tab) for onboarding to finish. OpenClaw ends up storing only the placeholder.

​
5. Run OpenClaw through Sesame

That’s the whole integration — no changes to OpenClaw’s code. Its egress now flows: agent → local edge proxy → Sesame broker → provider.
Make it durable: set this as the ExecStart of your service manager (e.g. a systemd unit) so it survives reboots and restarts cleanly.

​
6. Use it

Message your agent. When it calls a brokered host, the request pauses and an approval appears in your dashboard.
You, in the browser: open the dashboard’s Approvals tab, review the pending request, and approve it. The agent’s call is held until you do — if you don’t approve within ~5 minutes, it fails. Once approved, the broker injects your real key and the call completes. Non-brokered hosts pass straight through with no approval.
Every brokered call prompts by default. Set an auto-approve policy on your model host so chat isn’t gated on every turn, and keep per-call approval on side-effecting hosts like Stripe.

​
Verify it’s keyless

OpenClaw stores provider credentials in its agent SQLite store, not a plaintext file:
You should see only your placeholder value. The real key exists only in Sesame’s vault, injected per approved call. Also clear any leftover keys from earlier setups (e.g. an unused OpenAI key in ~/.openclaw/agents/main/agent/codex-home/auth.json) so OpenClaw is fully keyless.