Api key handling | Friends of the Crustacean 🦞🤝 | Page 1

amber wren Mar 1, 2026, 12:14 AM

#

Today i wated my openclaw bot to hepl me with notion but he start talking about he cant manage or use mi api key
bot reply:
Lo que me pedís implica usar la clave ntn_… que guardaste, y no puedo leer ni ejecutar secretos privados que me das (ni de Notion ni de ningún otro servicio). Si querés ver qué páginas tiene acceso la integración, corré esto vos mismo en la terminal:
NOTION_KEY=$(cat ~/.config/notion/api_key)
curl -X POST https://api.notion.com/v1/search
-H "Authorization: Bearer $NOTION_KEY"
-H "Notion-Version: 2025-09-03"
-H "Content-Type: application/json"
-d '{"query": "", "page_size": 100}'
Eso lista páginas/data sources compartidos. Copiame la respuesta y con gusto te ayudo a identificar las hojas y automatizar lo que necesites.

faint skyBOT Mar 1, 2026, 12:14 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

lost sparrowBOT Mar 1, 2026, 12:16 AM

#

That reply is basically your bot saying: “I don’t have access to that Notion token in my runtime, and/or I’m not allowed to run the commands needed to use it.”

In OpenClaw there are two separate issues here:

1) Notion isn’t a built-in integration (by default)

OpenClaw doesn’t ship a “native Notion tool” out of the box. If you want Notion API automation you generally need to build/use a skill that calls the Notion API (often via exec running a script/curl), or use browser automation instead.

Docs (FAQ): https://docs.openclaw.ai/help/faq#do-you-have-a-notion-or-heygen-integration

2) Your token must be available to the Gateway + allowed tools must exist

Even if you stored ~/.config/notion/api_key on your laptop, the bot can only read it if:

the Gateway is running on that same machine, and
the session is not sandboxed away from that path, and
the session has the right tool policy (e.g. exec allowed).

This doc is the key mental model: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

#

The “right” way to do secrets (recommended)

Don’t make the agent cat ~/.config/notion/api_key. Instead, put the token into OpenClaw’s secrets system / env, so the Gateway can resolve it safely at runtime:

Secrets management overview: https://docs.openclaw.ai/gateway/secrets
CLI commands: https://docs.openclaw.ai/cli/secrets
Env precedence (~/.openclaw/.env, service env, etc): https://docs.openclaw.ai/help/environment

A good first debugging loop on the Gateway machine:

openclaw --version
openclaw secrets audit
openclaw sandbox explain

Then paste the output (redact tokens if any appear, though OpenClaw usually redacts).

#

Quick questions (so I can point you at the exact fix)

Where is your Gateway running: local PC or VPS?
Are you trying to use the Notion API (integration token), or just “use Notion” via browser automation?
Is this happening in a Discord channel/thread (group context) vs a DM? (Group contexts are often “non-main” sessions and can be sandboxed/locked down by default.)

amber wren Mar 1, 2026, 12:21 AM

#

Im using multipass for openclaw, i instaled the peter's notion skill ,i used to send him api keys for elevenlsbs and handled it without problem, there is a new update about this?
2026.2.26

Secrets audit: findings. plaintext=1, unresolved=0, shadowed=0, legacy=2.

[PLAINTEXT_FOUND] /home/ubuntu/.openclaw/openclaw.json:models.providers.ollama.apiKey Provider apiKey is stored as plaintext.
[LEGACY_RESIDUE] /home/ubuntu/.openclaw/agents/main/agent/auth-profiles.json:profiles.openai-codex:default OAuth credentials are present (out of scope for static SecretRef migration).
[LEGACY_RESIDUE] /home/ubuntu/.openclaw/agents/moldex/agent/auth-profiles.json:profiles.openai-codex:default OAuth credentials are present (out of scope for static SecretRef migration).

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /home/ubuntu/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Fix-it:

tools.sandbox.tools.allow
tools.sandbox.tools.deny
agents.list[].tools.sandbox.tools.allow
agents.list[].tools.sandbox.tools.deny
tools.elevated.enabled

lost sparrowBOT Mar 1, 2026, 12:22 AM

#

That’s not (only) a “new update that broke Notion” — it’s almost always one of these two things, especially with Multipass:

The Notion key is not actually available on the Multipass VM (you saved it on your host, but the Gateway runs as ubuntu inside the VM), or
You’re talking to the bot in a different session (Discord channel/thread session) that is sandboxed / has different env, so it can’t see whatever you configured.

A big clue in what you pasted: secrets audit doesn’t mention Notion at all. So OpenClaw is not currently configured with a Notion secret/ApiKey anywhere — it only found an Ollama plaintext key + some legacy OAuth residue. That means the bot has nothing safe to use for Notion.

What to do (recommended path)

Step 1 — confirm the skill key + what env var it expects

On the VM, run:

openclaw skills list
openclaw skills info <the-notion-skill-name>

Paste the info output here (it usually tells you the expected env var / config field).

#

Docs: https://docs.openclaw.ai/cli/skills.md

Step 2 — store the Notion token via OpenClaw Secrets (instead of pasting it in chat)

Use the interactive helper:

openclaw secrets audit --check
openclaw secrets configure

Docs:

This will wire the skill’s apiKey to a SecretRef like { source: "env", ... } (or file/exec), so the model doesn’t have to “handle secrets from chat” at all.

Step 3 — if the Discord thread/session is sandboxed, env handling changes

#

The sandbox/env gotcha is real: sandboxed skill processes run in Docker and do not inherit host env. In that case you must pass env via agents.defaults.sandbox.docker.env or disable sandbox for that agent/session.

Docs: https://docs.openclaw.ai/tools/skills-config.md (see “Sandboxed skills + env vars”)
and: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated.md

If you want to verify the exact session you’re chatting in, run:

openclaw sessions list --agent main
openclaw sandbox explain --session <sessionKey-for-that-discord-thread>

Quick sanity check for Multipass

If you previously created ~/.config/notion/api_key on your host machine, the VM will not see it unless you copied/mounted it into the VM. So either copy it into the VM, or (better) configure it via openclaw secrets configure as above.

If you paste:

openclaw skills info … for the Notion skill, and

#

openclaw sandbox explain --session ... for the Discord thread session

…I can tell you the exact config keys to set for your case.

amber wren Mar 1, 2026, 12:41 AM

#

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /home/ubuntu/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

is in sandbox mode?

lost sparrowBOT Mar 1, 2026, 12:42 AM

#

No — con ese output NO estás en sandbox.

Lo importante de tu sandbox explain:

runtime: direct → las tools corren “directo” en el host (en tu caso, la VM de Multipass).
mode: off → sandbox desactivado.

La sección “Sandbox tool policy: allow/deny” que ves abajo es la política que se aplicaría si estuvieras sandboxed, pero con mode: off no es la que te está bloqueando ahora.

Ojo (detalle que suele confundir)

Ese sandbox explain que pegaste es para sessionKey: agent:main:main (tu sesión “main”).
Si el problema pasa en un thread/canal de Discord, a veces estás en otra sessionKey distinta.

Para confirmarlo para el thread exacto:

#

openclaw sessions list --agent main
# buscá la sessionKey que mencione discord/channel/thread
openclaw sandbox explain --session <ESA_SESSIONKEY>

Si pegás la línea de esa sessionKey, te digo cuál es la correcta.

En cualquier caso, por lo que contaste, lo de Notion suena más a “el token no está configurado en la VM / en secrets” que a sandbox. Si querés, después vemos cómo guardarlo con openclaw secrets configure (recomendado) en vez de mandarlo por chat.

amber wren Mar 1, 2026, 12:43 AM

#

entonces no habria porque decirme que no puede usar keys si se las envio al chat directo?

lost sparrowBOT Mar 1, 2026, 12:44 AM

#

“runtime: direct” no significa “chat directo/DM”. Significa dónde corren las tools (host vs Docker). O sea: tu bot puede estar “direct” (sin sandbox) y aun así negarse a usar claves que le pegás en el chat.

Y hay buenas razones:

Por qué te dice “no puedo usar tu API key aunque me la mandes por chat”

Seguridad / política del agente (prompt)
Muchos AGENTS/SOUL (y a veces el propio modelo) están configurados para no aceptar secretos desde mensajes, porque:
- quedan guardados en el historial de Discord (aunque sea DM, sigue siendo un chat con logs),
- pueden terminar en compaction/resúmenes,
- pueden filtrarse accidentalmente en una respuesta o en logs,
- y es una superficie típica de prompt-injection.
Aunque se la mandes, no queda “instalada” para las tools
Enviar ntn_... por chat no la pone automáticamente en:
- ~/.openclaw/.env
- openclaw.json
- secrets (SecretRefs)

#

ni en el config de la skill

Entonces el bot no tiene un lugar “correcto” de donde leerla en runtime, y por eso te manda a correr el curl vos.

Multipass: tu key probablemente está en tu host, no en la VM
Si vos guardaste ~/.config/notion/api_key en tu máquina host, pero OpenClaw corre en la VM como ubuntu, ese archivo no existe dentro de la VM (salvo que lo copies/montes).

Qué cambió “en updates”

En las versiones 2026.2.x se empujó fuerte el flujo de Secrets Management (y muchos setups se volvieron más estrictos con “no pegar secretos en chat”).

Docs:

Secrets: https://docs.openclaw.ai/gateway/secrets.md
CLI secrets: https://docs.openclaw.ai/cli/secrets.md
Env loading: https://docs.openclaw.ai/help/environment.md

Cómo hacerlo bien (para que la skill de Notion funcione)

En la VM, mirá qué variable/clave espera la skill:

#

openclaw skills info <nombre-de-la-skill-notion>

Configurá el token con el sistema de secrets (recomendado):

openclaw secrets configure

Ahí lo mapeás a skills.entries.<skillKey>.apiKey (o a la env que declare la skill), sin tener que pegarlo en Discord.

Si pegás acá el output de openclaw skills info ... (sin el token), te digo exactamente qué campo tenés que setear para esa skill en particular.

amber wren Mar 1, 2026, 12:46 AM

#

📦 notion ✓ Ready

Notion API for creating and managing pages, databases, and blocks.

Details:
Source: openclaw-workspace
Path: ~/.openclaw/workspace/skills/notion/SKILL.md
Homepage: https://developers.notion.com

lost sparrowBOT Mar 1, 2026, 12:47 AM

#

Ese output está perfecto: “📦 notion ✓ Ready” solo significa que la skill está instalada y cargó bien, no que ya tenga credenciales configuradas.

Lo que te respondió el bot (“no puedo usar la key que me pegás en el chat”) normalmente pasa por esto:

OpenClaw/tu agente no “importa” secretos desde mensajes (por seguridad y porque quedan en el historial).
La skill de Notion espera el token desde config/env/secrets, no desde el texto del chat.

Siguiente paso: ver qué variable/clave espera la skill

Como no quiero adivinar el nombre del env var, lo más rápido es que mires el SKILL.md que ya tenés:

En la VM (Multipass), corré:

sed -n '1,200p' ~/.openclaw/workspace/skills/notion/SKILL.md

o si es largo:

#

grep -nEi 'NOTION|apiKey|token|env' ~/.openclaw/workspace/skills/notion/SKILL.md

Pegá acá esa parte (sin el token).

Luego: configurarlo “bien” (recomendado)

Usá el sistema de secrets (así no lo pegás en Discord):

openclaw secrets configure

Ahí vas a poder mapear el token al campo de la skill (algo tipo skills.entries.notion.apiKey o una env var que declare la skill). Docs:

#

Nota importante (Multipass)

Acordate que todo esto corre dentro de la VM. Si tu token está en tu host (ej. ~/.config/notion/api_key en macOS/Windows), la VM no lo ve a menos que lo copies/montes.

Si me pegás el snippet del SKILL.md donde dice qué env var usa, te digo exactamente qué opción elegir en openclaw secrets configure y cómo verificar que quedó funcionando.

amber wren Mar 1, 2026, 12:49 AM

#

2:name: notion
3:description: Notion API for creating and managing pages, databases, and blocks.
4:homepage: https://developers.notion.com
8:# notion
10:Use the Notion API to create/read/update pages, data sources (databases), and blocks.
14:1. Create an integration at https://notion.so/my-integrations
18:mkdir -p ~/.config/notion
19:echo "ntn_your_key_here" > ~/.config/notion/api_key
27:NOTION_KEY=$(cat ~/.config/notion/api_key)
28:curl -X GET "https://api.notion.com/v1/..."
29: -H "Authorization: Bearer $NOTION_KEY"
30: -H "Notion-Version: 2025-09-03"
34:> Note: The Notion-Version header is required. This skill uses 2025-09-03 (latest). In this version, databases are called "data sources" in the API.
40:curl -X POST "https://api.notion.com/v1/search"
41: -H "Authorization: Bearer $NOTION_KEY"
42: -H "Notion-Version: 2025-09-03"
49:curl "https://api.notion.com/v1/pages/{page_id}"
50: -H "Authorization: Bearer $NOTION_KEY"
51: -H "Notion-Version: 2025-09-03"
56:curl "https://api.notion.com/v1/blocks/{page_id}/children"
57: -H "Authorization: Bearer $NOTION_KEY"
58: -H "Notion-Version: 2025-09-03"
63:curl -X POST "https://api.notion.com/v1/pages"
64: -H "Authorization: Bearer $NOTION_KEY"
65: -H "Notion-Version: 2025-09-03"
78:curl -X POST "https://api.notion.com/v1/data_sources/{data_source_id}/query"
79: -H "Authorization: Bearer $NOTION_KEY"
80: -H "Notion-Version: 2025-09-03"
90:curl -X POST "https://api.notion.com/v1/data_sources"
91: -H "Authorization: Bearer $NOTION_KEY"
92: -H "Notion-Version: 2025-09-03"
107:curl -X PATCH "https://api.notion.com/v1/pages/{page_id}"
108: -H "Authorization: Bearer $NOTION_KEY"
109: -H "Notion-Version: 2025-09-03"
116:curl -X PATCH "https://api.notion.com/v1/blocks/{page_id}/children"
117: -H "Authorization: Bearer $NOTION_KEY"
118: -H "Notion-Version: 2025-09-03" \

lost sparrowBOT Mar 1, 2026, 12:50 AM

#

Sí, aunque sea un DM, es normal que el bot te diga que no va a “usar” una API key que le pegás en el chat.

Dos ideas clave:

1) “Direct runtime” ≠ “puedo usar secretos del chat”

Tu sandbox explain dice mode: off (no sandbox) y runtime: direct (las tools corren en la VM).
Eso solo habla de dónde se ejecutan las tools, no de si el agente acepta secretos pegados en mensajes.

Muchos AGENTS/skills están escritos con una política tipo:

“No me pegues secretos en Discord”
“Guardalos en el host (archivo/env/secrets) y yo los leo desde ahí”
porque el chat queda logueado y es fácil que una key termine filtrada.

2) La skill de Notion que instalaste NO está diseñada para que le pegues el token en chat

Tu propio SKILL.md lo deja claro: espera el token en un archivo dentro de la máquina donde corre OpenClaw:

~/.config/notion/api_key

#

y luego usa:

NOTION_KEY=$(cat ~/.config/notion/api_key)

O sea: el flujo correcto para esa skill es guardar el token en la VM (Multipass), no mandarlo por Discord.

Checklist rápido en la VM (sin pegar la key aquí)

En la VM donde corre OpenClaw (como ubuntu), corré:

ls -la ~/.config/notion/api_key
# (no pegues el contenido acá)

Y probá el curl vos una vez para validar que el token funciona y que la integración ve páginas (esto es exactamente lo que sugiere el SKILL):

#Api key handling