Connect OpenClaw

Use these steps with 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

openclaw mcp probe also runs as a separate process that reads the file and dials the server itself. It reports success even when the running agent still uses 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 — with a Hub key of any capability, tools such as hub_list_installed_apps, and with a Memory key that has MCP and Intents, tools such as memory_recall. If ci-memory shows zero, the key is missing the Intents scope — see the scope trap.

openclaw mcp doctor checks the saved definitions for local setup problems without connecting, and warns when a header holds a literal bearer token instead of an ${ENV_VAR} reference. Add --probe to run the live connection check as well.

If both servers probe cleanly and the running agent still has no Companion tools, check its tool profile. Embedded OpenClaw exposes configured MCP tools in the coding and messaging profiles, the minimal profile hides them, and tools.deny: ["bundle-mcp"] turns them off explicitly.

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, and both end with a gateway restart — the config is read at startup. To turn parts of the integration off without uninstalling, set any of CI_MEMORY_CONTEXT_ENABLED, CI_MEMORY_RECALL_ENABLED, CI_MEMORY_TURN_ENABLED, CI_MEMORY_WRITE_ENABLED, CI_INTENTS_ENABLED, or CI_INTENT_TOOLS_ENABLED to false in the environment of the gateway process. All are on by default. Plugin releases after the pinned 2026.8.3 also read CI_DISPATCH_ENABLED. The Companion OpenClaw app page says what each one controls.

flowchart TB
    subgraph official["The official way — on the machine running OpenClaw"]
        A["openclaw plugins install<br/>npm:@companionintelligence/openclaw-memory"] --> B["Edit openclaw.json:<br/>slots.memory, entries, hooks,<br/>tools.alsoAllow, session-memory off"]
    end
    subgraph hub["The cihub connect way — on the Hub host"]
        X["cihub connect openclaw<br/>probes the key, installs the pinned plugin,<br/>writes the config block below"]
    end
    B --> C["openclaw daemon restart"]
    X --> C
    C --> D["openclaw plugins inspect<br/>status: loaded, selected memory slot"]
    D --> E["Have a conversation, then look for<br/>the turn in the Companion Memory dashboard"]

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 to 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.