Config cleanup

[glad forge]

Hi krill, I want to clean up my config and get rid of discord and whatsapp channels, just leaving Telegram, you can find the config here, please let me know what I should do https://cl1p.net/4560
I'm using version 2026.5.12

[subtle cave]

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

[arctic galleon]

I pulled the paste and checked the current docs. Important first: that paste contains live Telegram bot tokens, a Discord bot token, a gateway token, and a Brave key. Treat them as exposed and rotate them. Don’t reuse the pasted values.

For the config cleanup, the pieces to remove are:

# optional but sensible first
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S)

openclaw config unset channels.discord
openclaw config unset channels.whatsapp
openclaw config unset plugins.entries.discord
openclaw config unset plugins.entries.whatsapp

Then remove Discord/WhatsApp from plugins.allow, leaving Telegram in. Based on your paste, that allowlist would become roughly:

[arctic galleon]

["brave","firecrawl","google","llm-task","lmstudio","lobster","memory-core","memory-wiki","openrouter","qwen","telegram"]

Also remove the WhatsApp binding at the top:

{
  "agentId": "main",
  "match": {
    "channel": "whatsapp",
    "accountId": "default"
  }
}

Keep the four Telegram bindings you already have: sql, default, lead-scout, and portfolio-guardian.

[arctic galleon]

After editing:

openclaw gateway restart
openclaw doctor
openclaw status --all

Your cleaned channels section should only have telegram. Keep channels.telegram.accounts..., but replace every bot token after rotating them in BotFather.

Docs I checked:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/channels/telegram
https://docs.openclaw.ai/gateway/configuration
https://docs.openclaw.ai/cli/config

One extra safety note: disabling WhatsApp in config is enough to stop using it. Don’t delete WhatsApp auth/state until Telegram is confirmed working; if you clean it later, use trash/move-aside, not rm.

[glad forge]

That seems to have worked, is there any housekeeping I need to do on whatsapp and discord itself?

[arctic galleon]

Yep. Since OpenClaw is now no longer loading those channels, the remaining housekeeping is mostly cleanup/revocation on the provider side:

Discord

• In the Discord Developer Portal, reset/revoke that bot token since it was pasted publicly.
• If you do not plan to use that bot anymore, remove the bot from any Discord servers it was added to.
• If the whole app is no longer needed, delete the Discord application in the Developer Portal.
• If you keep the app around, make sure the old token is not sitting in env vars like DISCORD_BOT_TOKEN.

WhatsApp

• If it was linked through WhatsApp Web/Baileys, open WhatsApp on your phone: Settings → Linked devices, then unlink the OpenClaw/session device.
• If you have local WhatsApp auth/session folders, don’t delete them immediately. Move them aside or trash them after Telegram has been stable for a bit, so you can recover if needed.
• Check your shell/service env too, in case anything like WhatsApp-related credentials or old channel vars are still set.

Then do one final sanity pass:

[arctic galleon]

openclaw doctor
openclaw status --all
openclaw logs --follow

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. Helps Answer Overflow index the cleanup path for the next person. 🦞

[glad forge]

I can't see a linked device on my phone

[arctic galleon]

That’s fine. If WhatsApp doesn’t show a linked device, then there may be nothing left to unlink on the phone side.

The OpenClaw-side cleanup for WhatsApp auth is:

openclaw channels logout --channel whatsapp

If you had named WhatsApp accounts, repeat with the account id:

openclaw channels logout --channel whatsapp --account default

Docs say that clears the WhatsApp auth state for that account. After that, restart/check:

[arctic galleon]

openclaw gateway restart
openclaw doctor
openclaw status --all

I’d avoid manually deleting credential folders unless you’re sure everything is stable. If you do clean files later, move/trash them instead of hard-deleting. Relevant docs: https://docs.openclaw.ai/channels/whatsapp

[glad forge]

I'm on the latest update but doctor does have this message

This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), then rerun doctor.

[arctic galleon]

That doctor message is informational, not necessarily an error.

It means your OpenClaw install is an npm/pnpm package install, not a source/git checkout. In that install mode, doctor can’t git pull the repo for you, so it tells you to use the package updater path instead.

If you already ran the updater and openclaw --version says the expected/latest version, you can ignore that specific message. It’s not related to removing Discord/WhatsApp.

Useful checks:

openclaw --version
openclaw update status
openclaw status --all

Only run this if you actually want the package-manager update path again:

[arctic galleon]

openclaw update
openclaw doctor

Docs: https://docs.openclaw.ai/gateway/doctor and https://docs.openclaw.ai/install/development-channels

[glad forge]

ok. so everthing seems to be working. Do you have any other general comments about the config?

[arctic galleon]

A few general comments, based on the config you pasted earlier:

• Rotate every secret that was in the paste. Telegram bot tokens, Discord token, gateway token, Brave key. That’s the one I’d treat as mandatory.
• Move secrets out of plain config when convenient. Env vars or SecretRefs make future sharing much safer: https://docs.openclaw.ai/gateway/secrets
• Your gateway was bound to LAN and had some Control UI break-glass flags enabled: allowInsecureAuth, dangerouslyAllowHostHeaderOriginFallback, dangerouslyDisableDeviceAuth. If you don’t specifically need those, turn them off and prefer gateway.bind: "loopback" or Tailscale with normal token auth.
• tools.allow: ["*"] plus exec security: "full" / ask: "off" is powerful. Fine for a single trusted operator box, but it means “messages that are authorized can do a lot.” If this is Telegram-only and only your numeric user ID is allowlisted, that may be acceptable; just be intentional.
• Telegram top-level groupPolicy: "open" is worth reviewing. If you don’t need group use, set it to disabled or allowlist. For one-owner use, dmPolicy: "allowlist" with your numeric ID is the right shape.
• Prune unused plugins over time. You already started by removing Discord/WhatsApp; same idea applies to anything else you don’t actively use.

Best follow-up command:

openclaw security audit --deep

Then fix the high/critical items it reports, not every warning blindly. Docs: https://docs.openclaw.ai/gateway/security and https://docs.openclaw.ai/gateway/configuration.

[glad forge]

As you can see I have multiple agents on their own workspace, do I need to keep the main workspace?

[arctic galleon]

Short answer: yes, keep it if main is still your default/fallback agent or if any binding still routes to agentId: "main".

From your earlier config, you still had a Telegram default binding going to main, so that workspace is still active:

{ "agentId": "main", "match": { "channel": "telegram", "accountId": "default" } }

OpenClaw’s default workspace is ~/.openclaw/workspace, and single-agent/default routing uses agentId: main. The workspace is where that agent’s AGENTS/SOUL/USER/TOOLS/HEARTBEAT files, memory files, local skills, and notes live.

You only stop needing the main workspace if you intentionally do all of this:

• route every active Telegram account to some non-main agent
• set another agent as default: true in agents.list
• confirm no cron/heartbeat/hook/session still targets main
• move/copy any useful memory, skills, or persona files out of ~/.openclaw/workspace

[arctic galleon]

Even then, I’d archive it instead of deleting it:

mv ~/.openclaw/workspace ~/.openclaw/workspace.archived-main
openclaw doctor
openclaw gateway restart

My recommendation: keep main as the boring default/admin workspace unless you have a strong reason to remove it. It’s useful as the fallback agent and a safe place for shared operational notes.

Docs: https://docs.openclaw.ai/concepts/multi-agent and https://docs.openclaw.ai/gateway/configuration

[glad forge]

ok, apart from that, anything about the config worth looking at?

[arctic galleon]

A few config-specific things I’d still look at, beyond the main workspace question:

• Plaintext secrets: this is still the biggest one. Move bot/API/gateway tokens to env vars or SecretRefs once you’ve rotated them.
• Gateway exposure: you had gateway.bind: "lan" plus Control UI break-glass flags. If you only use this locally, switch back to loopback. If you need remote access, prefer Tailscale/reverse proxy + normal auth rather than keeping the dangerous flags.
• Tool power: tools.allow: ["*"] with exec full/no-ask is convenient, but very broad. With a tightly allowlisted Telegram user it can be fine, but I’d avoid exposing that to groups or open policies.
• Telegram group policy: if Telegram is mostly DMs, set group handling stricter or disabled. groupPolicy: "open" is broader than most single-user setups need.
• Unused providers/plugins: prune anything you don’t actively use. Smaller config = fewer surprises during updates.
• Local model entries: make sure your custom/local model definitions are actually ones you use and that their context/max-token settings match the backend. Bad model metadata can cause weird runtime behavior later.
• Memory/wiki path: your memory-wiki config had an absolute vault path. Worth confirming that path still exists and is intentionally shared with the agents that need it.

Best next step is still:

openclaw security audit --deep
openclaw status --all

[arctic galleon]

If those are clean apart from warnings you knowingly accept, I’d stop tinkering. Config cleanup has diminishing returns fast. 🦞

[glad forge]

actually there is a reference to pibrain, I no longer need that, how do I remove it

[arctic galleon]

In your paste the reference was the custom Ollama model entry:

models.providers.ollama.models[] with id: "pi-brain".

First confirm where it still appears:

rg -n -i 'pi[-_ ]?brain' "$(openclaw config file)"

If it’s only in models.providers.ollama.models, remove just that model entry like this:

cp "$(openclaw config file)" "$(openclaw config file).bak.$(date +%Y%m%d-%H%M%S)"

openclaw config set models.providers.ollama.models "$(

[arctic galleon]

  openclaw config get models.providers.ollama.models --json     | jq -c 'map(select(.id != "pi-brain" and .name != "pi-brain"))'
)" --strict-json --replace

openclaw config validate
openclaw gateway restart

If you don’t have jq, just open the config file and delete the single object whose id / name is pi-brain from the models.providers.ollama.models array. Don’t remove the whole ollama provider unless you’re done with all Ollama/local models.

Docs for this bit: https://docs.openclaw.ai/cli/config and https://docs.openclaw.ai/gateway/configuration.

[glad forge]

actually I can delete all ollama models, all my models are on beelink

[arctic galleon]

Yep, if Beelink is your actual model host and nothing should use local Ollama on this machine, remove the whole Ollama provider entry rather than deleting models one by one.

Before removing it, check whether anything still points at ollama/...:

rg -n -i 'ollama|pi-brain|llama3|qwen|glm|phi4|kimi' "$(openclaw config file)"

Then back up and unset the provider:

cp "$(openclaw config file)" "$(openclaw config file).bak.$(date +%Y%m%d-%H%M%S)"

openclaw config unset models.providers.ollama
openclaw config validate
openclaw gateway restart

[arctic galleon]

openclaw models status

If config validate or models status complains that an agent/default model still references ollama/..., change that model setting to the Beelink provider/model first, then rerun the unset.

I would not remove the Ollama app/package itself yet unless you’re sure nothing else on that box uses it. Config cleanup first, uninstall later if needed.

[glad forge]

One last thing, is it possible to install agentmail as a plugin or MCP server, rather than a skill

[arctic galleon]

Yes — MCP is the better fit here. I found an official AgentMail MCP server (agentmail-mcp); I don’t see an OpenClaw-native AgentMail plugin in the current docs/source.

In OpenClaw, add it to the MCP server registry:

openclaw mcp set agentmail '{
  "command": "npx",
  "args": ["-y", "agentmail-mcp"],
  "env": {
    "AGENTMAIL_API_KEY": "YOUR_AGENTMAIL_API_KEY"
  }
}'

Then check it’s saved:

[arctic galleon]

openclaw mcp list
openclaw mcp show agentmail --json
openclaw gateway restart

If you only want a smaller tool surface, AgentMail’s MCP server supports --tools:

openclaw mcp set agentmail '{
  "command": "npx",
  "args": ["-y", "agentmail-mcp", "--tools", "get_message,send_message,reply_to_message"],
  "env": {
    "AGENTMAIL_API_KEY": "YOUR_AGENTMAIL_API_KEY"
  }
}'

[arctic galleon]

I’d avoid pasting the real API key into Discord or any shared config paste. If you can, put it in the gateway host/service env instead, or move it into your secrets setup after confirming the MCP server works.

Docs:
https://docs.openclaw.ai/cli/mcp
https://github.com/agentmail-to/agentmail-mcp

[glad forge]

AGENTMAIL_API_KEY is currently in .env

[arctic galleon]

Good — then don’t put the actual key in the MCP config. Store a reference to the env var:

openclaw mcp set agentmail '{
  "command": "npx",
  "args": ["-y", "agentmail-mcp"],
  "env": {
    "AGENTMAIL_API_KEY": "${AGENTMAIL_API_KEY}"
  }
}'

The single quotes matter: they keep your shell from expanding the value before OpenClaw saves the config.

Two checks:

[arctic galleon]

openclaw mcp show agentmail --json
openclaw gateway restart

For daemon installs, the safest place for that env var is the OpenClaw state env file, usually:

~/.openclaw/.env

A project/workspace .env can be more dependent on the gateway’s working directory, especially under launchd/systemd. If AGENTMAIL_API_KEY is already in ~/.openclaw/.env, you’re in the good shape. If it’s only in some repo/workspace .env, I’d move/copy just that one var into ~/.openclaw/.env and restart the gateway.

[glad forge]

Thats done, how do I remove the skill

[arctic galleon]

Skills are just folders, so removal is filesystem cleanup plus checking skill allowlists.

First find where it is installed:

openclaw skills list
find ~/.openclaw -path '*/skills/*/SKILL.md' | grep -i agentmail

Most likely it is in one of these:

~/.openclaw/workspace/skills/agentmail/
~/.openclaw/workspace-<agent>/skills/agentmail/
~/.openclaw/skills/agentmail/

[arctic galleon]

Move it aside rather than hard-deleting:

mkdir -p ~/.openclaw/archived-skills
mv ~/.openclaw/workspace/skills/agentmail ~/.openclaw/archived-skills/agentmail.$(date +%Y%m%d-%H%M%S)

Adjust the path if find shows it under a different agent workspace. If the folder name is agentmail-mcp or similar, use that folder name instead.

Then check whether your config explicitly allowlists it:

rg -n -i 'agentmail' "$(openclaw config file)"

If it appears under agents.defaults.skills or agents.list[].skills, remove that entry from the list too. Afterward:

[arctic galleon]

openclaw skills list
openclaw gateway restart

Docs: https://docs.openclaw.ai/tools/skills and https://docs.openclaw.ai/tools/clawhub

[glad forge]

will the agentmail mcp be visible to all agents?

[arctic galleon]

Mostly yes: openclaw mcp set agentmail ... stores it globally under mcp.servers.

Whether an agent actually sees the tools depends on that agent’s tool profile/policy. Current docs say configured MCP tools are exposed in normal coding and messaging tool profiles; minimal hides them.

If you want to hide all configured MCP tools from a specific agent, add a per-agent deny:

{
  agents: {
    list: [
      {
        id: "some-agent",
        tools: {
          deny: ["bundle-mcp"]
        }
      }

[arctic galleon]

    ]
  }
}

That denies the whole OpenClaw-managed MCP bundle for that agent, including AgentMail. I don’t think there’s a nice per-agent “only hide agentmail but keep other MCP servers” knob in the simple config path; for that I’d either keep AgentMail only on agents that need MCP access via tool policy, or split the workflow into a dedicated agent.

Docs: https://docs.openclaw.ai/cli/mcp and https://docs.openclaw.ai/tools

[glad forge]

I want them all to see it

[arctic galleon]

Then the global mcp.servers.agentmail setup is the right shape.

To make sure all agents can see it:

rg -n 'bundle-mcp|minimal|tools' "$(openclaw config file)"

Check for two things:

• no agent has tools.deny: ["bundle-mcp"]
• no agent you care about is using tools.profile: "minimal"

If an agent is set to minimal, switch it to a normal profile like messaging or coding depending on what that agent does. After changes:

[arctic galleon]

openclaw config validate
openclaw gateway restart

So: leave agentmail under mcp.servers, don’t deny bundle-mcp, and don’t use minimal for agents that should see MCP tools.

[glad forge]

should AGENTMAIL_API_KEY have quotes around the actual key value in the .env file?

[arctic galleon]

Usually no. Use the simple dotenv form:

AGENTMAIL_API_KEY=your_actual_key_here

Quotes are only needed if the value contains spaces, #, or other characters that dotenv might treat specially. Most API keys are safest unquoted.

If you do quote it, use normal double quotes and don’t add extra spaces:

AGENTMAIL_API_KEY="your_actual_key_here"

Avoid this:

[arctic galleon]

AGENTMAIL_API_KEY = "..."

After editing ~/.openclaw/.env, restart the gateway so the daemon picks it up.

[glad forge]

I can see double quotes around it already, is that correct?

[arctic galleon]

Yes, double quotes are valid in a .env file. Dotenv will parse:

AGENTMAIL_API_KEY="actual_key"

as the value actual_key, without including the quote characters.

That’s fine as long as they are normal straight quotes ("), not curly smart quotes, and there are no accidental extra spaces inside the quotes. After restarting the gateway, you can sanity-check without printing the key:

node -e 'require("dotenv").config({path: require("os").homedir()+"/.openclaw/.env"}); console.log(process.env.AGENTMAIL_API_KEY ? "AGENTMAIL_API_KEY loaded" : "missing")'

[silver widget]

cuál es el dashboard

active la IA desde google

[arctic galleon]

El dashboard es la interfaz web de OpenClaw / Control UI.

Si estás en la misma máquina donde corre el gateway, normalmente abre:

http://127.0.0.1:18789/

Si el gateway está en otra máquina/VPS, necesitas abrir la URL que te dio openclaw onboard, Tailscale, un túnel SSH, o la IP/host configurado para tu gateway.

Comandos útiles:

openclaw gateway status
openclaw status

Si te pide autenticación, usa el token/password del gateway configurado en gateway.auth.token o gateway.auth.password.

[arctic galleon]

Docs: https://docs.openclaw.ai/help/faq y https://docs.openclaw.ai/web/dashboard

[arctic galleon]

Perfecto. Si te refieres a que activaste Gemini/Google como IA, lo siguiente es comprobar que OpenClaw lo ve bien:

openclaw --version
openclaw models status
openclaw status

Si usas Gemini CLI, también verifica que el comando exista:

gemini --version

OpenClaw espera que el CLI de Gemini esté disponible como gemini en el PATH. La doc menciona instalarlo con npm install -g @google/gemini-cli o brew install gemini-cli, según tu sistema.

Docs:

[arctic galleon]

https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/gateway/cli-backends

[glad forge]

For the models you can see I have

        "contextWindow": 262144,
        "contextTokens": 200000,

is there any value in giving it the full 256K?

[arctic galleon]

Usually not much value.

contextWindow: 262144 is the model/native metadata. contextTokens: 200000 is an optional runtime cap: OpenClaw docs describe it as “use this when you want a smaller effective context budget than the model’s native contextWindow.”

I’d keep the 200K cap unless you’re regularly hitting context-limit errors on legitimate long tasks. Reasons:

• huge context costs more / runs slower on many backends
• quality often drops when you stuff the very top of the window
• it leaves room for tool results, system/context files, and output without riding the hard limit
• some local/proxy backends advertise a context size they don’t reliably handle in practice

If you do want to test it, set it close to but not exactly full, e.g. 240000, then watch logs/status for context or latency issues. I wouldn’t jump straight to full 262144 unless you have a clear need.

Docs: https://docs.openclaw.ai/gateway/configuration

[silver widget]

402 Credits exhausted. Daily and monthly credits are depleted. Top up or wait for daily reset.

[arctic galleon]

Ese error no es del dashboard: es del proveedor/modelo. Significa que la cuenta o key que estás usando ya no tiene créditos/cuota disponible.

Qué hacer:

openclaw models status
openclaw status --usage

Luego tienes 3 opciones:

• esperar al reset diario/mensual
• recargar créditos en el proveedor que estás usando
• cambiar a otro proveedor/modelo que sí tenga cuota configurada

Si tienes otro proveedor ya configurado, cambia el modelo desde OpenClaw con el selector de modelo / Control UI, o revisa la config con:

[arctic galleon]

openclaw config --section model

Para recomendaciones actuales de modelos, mejor pregunta en #models porque eso cambia rápido. Docs: https://docs.openclaw.ai/concepts/models