Connect OpenClaw

This page is for your own OpenClaw install — the one you installed from npm, not the Companion OpenClaw app from the Hub app store.

Nothing here requires a Companion build. The packaged app installs stock OpenClaw from npm; the only difference is that it arrives pre-wired.

Before you start

You need two API keys and the addresses of both servers.

<hub-url> and <memory-url> below are your two servers’ base URLs — everything before /api/mcp. Neither has a port you can assume, so take both from the Hub dashboard if you are unsure: Hub, Memory.

Add the servers

openclaw mcp add ci-hub --url "<hub-url>/api/mcp" --transport streamable-http --header "Authorization=Bearer <hub-key>"

openclaw mcp add ci-memory --url "<memory-url>/api/mcp" --transport streamable-http --header "Authorization=Bearer <memory-key>"

openclaw mcp probe

Editing the config by hand

openclaw mcp add writes ~/.openclaw/openclaw.json. You can edit it directly instead:

{
  "mcp": {
    "servers": {
      "ci-hub": {
        "url": "<hub-url>/api/mcp",
        "transport": "streamable-http",
        "headers": { "Authorization": "Bearer ${HUB_MCP_API_KEY}" }
      },
      "ci-memory": {
        "url": "<memory-url>/api/mcp",
        "transport": "streamable-http",
        "headers": { "Authorization": "Bearer ${CI_MEMORY_API_KEY}" }
      }
    }
  }
}

Setting the variable where the gateway can see it

The ${VAR} syntax itself is platform-neutral — OpenClaw substitutes it when the config loads. What differs is how you put the variable somewhere the gateway process inherits it.

# This shell only:
export CI_MEMORY_API_KEY='<memory-key>'
# Persist it: add that line to ~/.zshrc, ~/.bashrc, or the systemd unit's
# Environment= / EnvironmentFile= if the gateway runs as a service.

# This session only:
$env:CI_MEMORY_API_KEY = '<memory-key>'
 
# Persist for your user — new processes only, so restart the gateway afterwards:
[Environment]::SetEnvironmentVariable('CI_MEMORY_API_KEY', '<memory-key>', 'User')

The transport field must be streamable-http. OpenClaw is the client that names this field transport; Hermes omits it and Claude Code calls it type. Copying a working entry between clients without translating that field is a common failure.

After a hand edit, a running OpenClaw has to be told to pick it up:

openclaw mcp reload

This is easy to miss, because openclaw mcp probe is also a separate process that reads the file and dials the server itself — it will report success while the running agent is still on the old config.

Verify

Ask your agent to list what it can do, or check directly:

openclaw mcp probe

Expect both servers listed with a non-zero tool count. If ci-memory shows zero, the key is missing the Intents scope — see the scope trap.

Read the ! lines too. A server that errors during the probe — including one answering -32601 Method not found, the other symptom of a missing Intents scope — is reported as a diagnostic rather than listed with a count, so scanning only for 0 tools misses it.

Removing a server

Revoking a key does not remove the entry that used it, and a stale entry fails on every start:

openclaw mcp unset ci-memory

Do this whenever you rotate or revoke a key, or the client keeps trying the old credential.

First-class memory

Everything above gives your agent memory it can call. What it does not give you is memory that accumulates on its own — passive turn capture and bootstrap context injected at the start of a session. That comes from a memory-slot provider, OpenClaw’s plugins.slots.memory, which is a different mechanism from MCP entirely.

The provider is published as @companionintelligence/openclaw-memory. You do not need MCP configured to use it — the two are independent, and you can do this instead of the sections above if passive memory is all you want.

There are two ways to install it. They produce the same configuration.

The official way

openclaw plugins install npm:@companionintelligence/openclaw-memory@2026.8.3

{
  "plugins": {
    "slots": { "memory": "companionintelligence" },
    "entries": {
      "companionintelligence": {
        "enabled": true,
        "hooks": { "allowConversationAccess": true },
        "config": {
          "url": "<memory-url>",
          "token": "<memory-key>"
        }
      }
    }
  },
  "tools": { "alsoAllow": ["memory_store"] },
  "hooks": {
    "internal": { "entries": { "session-memory": { "enabled": false } } }
  }
}

openclaw daemon restart

openclaw plugins inspect companionintelligence --runtime --json

The proof that passive capture is actually on: have a short conversation, then look for the turn in the Companion Memory dashboard — or start a fresh session and ask about something from the last one. Nothing in that flow calls a memory tool by hand, which is the point.

The cihub connect way

If you are working on the Hub host itself, one command does the install and the configuration:

cihub connect openclaw --memory-url "<memory-url>" --memory-key "<memory-key>"

It probes the server before touching anything, installs the pinned plugin version, writes every key in the table above, and backs up your config first. Add --dry-run to see exactly what it would do and write nothing. You still restart the gateway afterwards — openclaw daemon restart — as the command’s output reminds you.

The pre-flight probe checks the key as well as the address — it calls an endpoint that requires the Memory scope, so a key that would fail silently at capture time is refused up front, with nothing written.

It configures the machine it runs on. If your agent lives on your laptop and the Hub is an appliance across the room, use the official way on the laptop — that split is the design, not a gap.

Optionally add --hub-url and --hub-key and it will register the Hub MCP server too, replacing the openclaw mcp add ci-hub step near the top of this page.

When memory does not accumulate

The command refused with “the memory slot is held by …”. Another provider is selected, and the configuration this page writes would take the slot from it. That selection was a deliberate choice you or a previous setup made, so cihub connect refuses to overwrite it without --force. (Plain openclaw plugins install does not touch the slot either way — which is why step 2 exists.)

Setup succeeded, tools appear, nothing is captured. Two usual causes, both silent. First, the key: wrong, or missing the Memory scope, or minted Read-only — the plugin swallows failed writes rather than break your session, and no check on this page can catch a bad key, so re-check the key before anything else. Second, hooks.allowConversationAccess: it must be true on the plugin’s own entry — not at the top level.

Session summaries still pile up in workspace memory/*.md files. The bundled session-memory hook is still enabled, keeping its parallel local memory alongside this provider.

Changes did nothing. A running gateway keeps its old config. openclaw mcp reload does not help here — it disposes MCP runtimes in the process that runs it, and this is not MCP. Restart the gateway with openclaw daemon restart, or by stopping and starting it yourself if you do not run it as a service.