Skip to main content

Troubleshooting

Supermemory is opaque until something goes wrong. These are the failures we see in practice and how to fix them.

"supermemory_installed: false" after setup​

intern-server reports this on every /ping. The cause is almost always one of these.

1. Keys missing from config.json​

Check:

jq '{has_key: (.supermemory_api_key // "" | length > 0),
     tag:     .supermemory_container_tag}' /root/config/config.json

If has_key is false or tag is empty, you haven't written the values yet — see Overview → Setup flow.

2. Plugin block missing from openclaw.json​

Check:

jq '.plugins.entries["openclaw-supermemory"]' /root/.openclaw/openclaw.json

If you see null, the sync from config.json → openclaw.json never ran. Fix:

sudo systemctl restart intern
sudo systemctl restart openclaw

3. Plugin enabled but unreachable​

OpenClaw will mark the plugin as installed but log errors on every memory write. Tail OpenClaw:

journalctl -u openclaw -f | grep supermemory

Look for:

SymptomLikely causeFix
401 unauthorizedAPI key is wrong, revoked, or rotated on supermemory.aiRe-issue a key in your Supermemory dashboard, write the new value into config.json, restart intern + openclaw.
ENOTFOUND api.supermemory.aiDNS / no internetping 1.1.1.1 and ping api.supermemory.ai to isolate.
ECONNREFUSED / network timeoutWi-Fi joined but no internet, or upstream outageVerify outbound HTTPS works; check status.supermemory.ai if available.
4xx on container_tagTag contains characters Supermemory doesn't acceptPick a simpler tag (alnum + - / _) and re-write config.json.

Memories aren't being recalled​

Plugin is reporting installed: true, OpenClaw is happy, but the Intern doesn't seem to remember anything.

  1. Confirm memories are actually being written:

    journalctl -u openclaw -f | grep "supermemory.add"

    You should see entries each time a conversation turn ends. If not, the plugin isn't being called — check openclaw.json for enabled: true.

  2. Confirm memories are being queried on each turn:

    journalctl -u openclaw -f | grep "supermemory.query"

  3. Inspect the container directly:

    SM_KEY=$(jq -r .supermemory_api_key /root/config/config.json)
    TAG=$(jq -r .supermemory_container_tag /root/config/config.json)
    curl -H "Authorization: Bearer $SM_KEY" \
         "https://api.supermemory.ai/v1/memories?container_tag=$TAG&limit=20"

    If the list is empty even though supermemory.add log lines exist, your container tag in openclaw.json likely drifted from config.json. Restart intern.service to re-sync.

Moving a device to a new owner​

If you're handing a device to someone else and want a clean memory namespace:

  1. Pick a new supermemory_container_tag (or have the new owner pick one) and update /root/config/config.json.
  2. Optionally rotate the supermemory_api_key to a key the new owner controls.
  3. Restart to sync: 
    sudo systemctl restart intern
    sudo systemctl restart openclaw

The old container tag is not deleted from Supermemory — old memories still exist server-side under the old tag. Delete them explicitly with the API call below if you want them gone.

Wiping memory only​

To clear all memories without changing the key or tag:

SM_KEY=$(jq -r .supermemory_api_key /root/config/config.json)
TAG=$(jq -r .supermemory_container_tag /root/config/config.json)

curl -X DELETE -H "Authorization: Bearer $SM_KEY" \
     "https://api.supermemory.ai/v1/containers/$TAG/memories"

The plugin keeps working — it just starts with a blank slate.