Agent can't access tools for config and cron after updating to the latest versions. | Friends of the Crustacean 🦞🤝 | Page 1

fallen eagle Feb 28, 2026, 11:55 AM

#

Hey Krill,

I have been using version 2026.2.13 for a while and it has been working great but I wanted to update to one of the latest versions to utilize the new features and fixes. I noticed all recent releases causes the agent to lose access to tools for managing cron, config and maybe others that I am not aware of.

Here are snippets from my config

  "commands": {
    "native": "auto",
    "nativeSkills": "auto",
    "restart": true,
    "ownerDisplay": "raw",
    "config": true
  },
  "skills": {
    "install": {
      "nodeManager": "npm"
    },
    "entries": {
      "voice-call": {
        "enabled": true
      },
      "weather": {
        "enabled": false
      }
    }
  },
  "tools": {
    "web": {
      "search": {
        "enabled": true,
        "apiKey": "..."
      },
      "fetch": {
        "enabled": false
      }
    },
    "media": {
      "audio": {
        "enabled": true,
        "maxBytes": 1073741824,
        "models": [
          {
            "type": "cli",
            "command": "/home/node/.local/bin/whisper",
            "args": [
              "--model",
              "base.en",
              "{{MediaPath}}"
            ],
            "timeoutSeconds": 6000
          }
        ]
      }
    }
  },

Let me know if you need any other information about my setup.

cedar oasisBOT Feb 28, 2026, 11:55 AM

#

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

odd hawkBOT Feb 28, 2026, 11:58 AM

#

A couple things changed in newer releases that can look like “the agent lost access to cron/config tools”, but it’s usually just policy / session / authorization getting stricter.

1) First: what exact version breaks?

Can you paste the output of:

openclaw --version

(and ideally which version you upgraded to).

2) Is it “/config stopped working” or “agent can’t call the cron/gateway tools”?

These are different systems:

/config … is a slash command (owner-only; must be a standalone /... message). It requires commands.config: true (you have that). Docs: https://docs.openclaw.ai/tools/slash-commands
Cron/config “tools” are the cron tool and the gateway tool (config.get/patch/apply/etc). Docs: https://docs.openclaw.ai/tools

If you can, run /context detail in the “broken” chat/thread and paste the Tools section. That will immediately show whether cron/gateway are missing from the injected tool list.

#

3) Most common cause: tool policy started excluding `cron` + `gateway`

In recent versions, if you have any restrictive tool policy (global, per-agent, per-provider, or sandbox), then cron/config tools can disappear.

Key rule (docs): if an allow list is non-empty, everything else is blocked.
Cron+gateway live in group:automation (cron, gateway). Docs: https://docs.openclaw.ai/tools and https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

So please check if you have any of these elsewhere in your config (you didn’t include them in the snippet):

tools.profile
tools.allow / tools.deny
tools.byProvider
tools.sandbox.tools.allow / tools.sandbox.tools.deny
agents.defaults.tools.* or agents.list[].tools.*

If you do have an allowlist, the fix is usually to include automation, e.g.:

#

tools: {
allow: ["group:automation"] // or explicitly: ["cron", "gateway"]
}
}

(If you already have tools.allow, append group:automation to your existing list — don’t replace it, or you’ll accidentally block other tools you rely on.)

4) Bonus gotcha: sandbox “non-main” sessions

If you run with agents.defaults.sandbox.mode: "non-main", Discord channels/threads often become “non-main” sessions, and then sandbox tool policy can kick in and block cron/gateway only in those contexts. The openclaw sandbox explain … command is the quickest way to see that. Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

If you paste:

openclaw --version
/context detail → Tools section (from a broken thread)
openclaw config get tools and openclaw config get agents.defaults.tools

#

…I can tell you exactly which policy line is cutting off cron/config.

fallen eagle Feb 28, 2026, 12:11 PM

#

I am currently on 2026.2.26 and have been using 2026.2.13 before.
Slash commands are working fine. It's the agent that can't call the tools.

Here is the output of the /context detail (too long for discord message limit. will include the relevant part only. let me know if I should send it as an attachment)

Tools: read, edit, write, exec, process, browser, canvas, nodes, message, tts, agents_list, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status, web_search, memory_search, memory_get

openclaw config get tools

{
  "web": {
    "search": {
      "enabled": true,
      "apiKey": "__OPENCLAW_REDACTED__"
    },
    "fetch": {
      "enabled": false
    }
  },
  "media": {
    "audio": {
      "enabled": true,
      "maxBytes": 1073741824,
      "models": [
        {
          "type": "cli",
          "command": "/home/node/.local/bin/whisper",
          "args": [
            "--model",
            "base.en",
            "{{MediaPath}}"
          ],
          "timeoutSeconds": 6000
        }
      ]
    }
  }
}

openclaw config get agents.defaults.tools

Config path not found: agents.defaults.tools

What is the easiest config to allow all tools, not just the automation ones?

odd hawkBOT Feb 28, 2026, 12:13 PM

#

That /context detail output is the giveaway: cron and gateway are missing entirely from the tool list, while everything else is there.

In current releases those two are treated as owner-only tools — so if OpenClaw doesn’t consider you “owner” for that Discord channel session, it strips cron/gateway before the model ever sees them (=> “tool not found”).

Why your `tools` config didn’t help

openclaw config get tools is only showing tool settings (web/media). It’s not a “tool allowlist”. You’re already effectively on “allow all tools” policy-wise (otherwise you’d be missing lots more than cron/gateway).

Fix: make OpenClaw recognize you as owner (Discord)

In the Discord channel/thread where it’s broken, run:

/whoami (or /id)
and copy your Discord user id.

Add yourself to the Discord guild allowlist (this is also just good hygiene for group channels):

{
channels: {

#

discord: {
groupPolicy: "allowlist",
guilds: {
"YOUR_GUILD_ID": {
users: ["YOUR_DISCORD_USER_ID"]
}
}
}
}
}

Then set the owner allowlist (this is what unlocks owner-only tools like cron/gateway):

#

commands: {
ownerAllowFrom: {
discord: ["YOUR_DISCORD_USER_ID"]
},
config: true,
restart: true
}
}

Restart the gateway, then re-check /context detail — you should now see cron, gateway in the Tools list.

If it still fails in Discord group channels but works in DMs

There’s a known regression around Discord group-channel owner resolution that matches your symptom (“senderIsOwner always false” → cron/gateway stripped): https://github.com/openclaw/openclaw/issues/22284

Workaround until it’s fixed: manage cron/config from a DM with the bot (or CLI), not from the guild channel.

#

Re: “easiest config to allow all tools”

You already have it: don’t set tools.profile, tools.allow, tools.deny, or sandbox tool allow/deny. (Optional explicit version is tools.profile: "full" — same behavior.)
But that still won’t expose cron/gateway unless you’re recognized as owner.

If you paste your /whoami output (just the ids, no secrets), I can tell you the exact string format to put into commands.ownerAllowFrom.

fallen eagle Feb 28, 2026, 12:15 PM

#

I use telegram. How would this translate to telegram config?

#

🧭 Identity
Channel: telegram
User id: 1359334095
Username: @fallen eagleAbdo
AllowFrom: 1359334095

odd hawkBOT Feb 28, 2026, 12:16 PM

#

On Telegram there’s no “guild/users” block like Discord — the closest equivalent is: your Telegram user ID in channels.telegram.allowFrom (and optionally a commands allowlist).

To make sure you’re treated as the owner (so owner-only tools like cron/gateway show up), do this:

In Telegram DM with the bot, run:

/whoami (or /id)
and copy the tg:... / numeric id it prints.

Add it to your Telegram config. Minimal “single-owner, full tools” shape:

{
channels: {
telegram: {
enabled: true,
botToken: "...",

#


// simplest + safest for a personal setup:
dmPolicy: "allowlist",
allowFrom: ["tg:123456789"],
},
},

commands: {
config: true,
restart: true,

// optional hardening: only *you* can run slash commands/directives
// (this is NOT the same thing as tool access, just command auth)
allowFrom: { telegram: ["tg:123456789"] },

#

// if your build supports it, this is the explicit “owner” allowlist:
ownerAllowFrom: { telegram: ["tg:123456789"] },
},
}

Notes:

Telegram allowlist entries can be tg:<id> / telegram:<id> / raw numeric id, and often @username too (docs mention all of these for Telegram allowlists).
If you keep dmPolicy: "pairing" you might still be authorized, but owner-only tools may still rely on explicit allowlists, so for “just me” setups I’d switch to allowlist.

After changing config + restart, check /context detail again — you should see cron and gateway in the tool list.

If you paste your Telegram /whoami output (just the id line), I can tell you the exact string to drop into allowFrom.

#

For Telegram, the “make me the owner / allow cron+gateway” equivalent is basically: put your Telegram user id in channels.telegram.allowFrom (and use dmPolicy: "allowlist").

From your /whoami:

Telegram user id: 1359334095

Minimal config (JSON5) that should restore owner-only tools like cron/gateway in Telegram DMs:

{
channels: {
telegram: {
enabled: true,
botToken: "123:abc",

dmPolicy: "allowlist",

#

// numeric is fine; tg:/telegram: prefixes are also accepted
allowFrom: ["tg:1359334095"],
},
},

commands: {
config: true,
restart: true,

// optional: lock *commands/directives* to just you
allowFrom: { telegram: ["tg:1359334095"] },
},
}

Then restart the gateway and verify in Telegram DM with:

#

/context detail → Tools should now include cron and gateway.

If they’re still missing after this (only in some chat contexts), paste the Telegram /context detail “Tools:” line — that would point to either (a) you’re not being recognized as owner in that session, or (b) a regression similar to the Discord one (owner resolution / sender normalization).

fallen eagle Feb 28, 2026, 12:25 PM

#

🧠 Context breakdown (detailed)
Workspace: /home/node/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 44,091 chars (~11,023 tok) (Project Context 29,915 chars (~7,479 tok))
Injected workspace files:

• AGENTS.md: OK | raw 12,572 chars (~3,143 tok) | injected 12,572 chars (~3,143 tok)
• SOUL.md: OK | raw 2,610 chars (~653 tok) | injected 2,610 chars (~653 tok)
• TOOLS.md: OK | raw 6,313 chars (~1,579 tok) | injected 6,313 chars (~1,579 tok)
• IDENTITY.md: OK | raw 278 chars (~70 tok) | injected 278 chars (~70 tok)
• USER.md: OK | raw 706 chars (~177 tok) | injected 706 chars (~177 tok)
• HEARTBEAT.md: OK | raw 167 chars (~42 tok) | injected 167 chars (~42 tok)
• BOOTSTRAP.md: MISSING | raw 0 | injected 0
• MEMORY.md: OK | raw 6,617 chars (~1,655 tok) | injected 6,617 chars (~1,655 tok)
Skills list (system prompt text): 3,582 chars (~896 tok) (10 skills)
Skills: gog, healthcheck, openai-whisper, skill-creator, video-frames, merge-pr, prepare-pr, review-pr, firecrawl, tomorrow-weather
Top skills (prompt entry size):
• tomorrow-weather: 482 chars (~121 tok)
• healthcheck: 456 chars (~114 tok)
• firecrawl: 392 chars (~98 tok)
• review-pr: 345 chars (~87 tok)
• prepare-pr: 334 chars (~84 tok)
• merge-pr: 327 chars (~82 tok)
• skill-creator: 261 chars (~66 tok)
• openai-whisper: 198 chars (~50 tok)
• gog: 197 chars (~50 tok)
• video-frames: 194 chars (~49 tok)
Tool list (system prompt text): 1,878 chars (~470 tok)
Tool schemas (JSON): 14,189 chars (~3,548 tok) (counts toward context; not shown as text)
Tools: read, edit, write, exec, process, browser, canvas, nodes, message, tts, agents_list, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status, web_search, memory_search, memory_get

#

Top tools (schema size):
• message: 4,220 chars (~1,055 tok)
• browser: 1,869 chars (~468 tok)
• nodes: 1,500 chars (~375 tok)
• exec: 1,037 chars (~260 tok)
• process: 949 chars (~238 tok)
• web_search: 870 chars (~218 tok)
• canvas: 661 chars (~166 tok)
• edit: 591 chars (~148 tok)
• sessions_spawn: 468 chars (~117 tok)
• read: 392 chars (~98 tok)
• write: 313 chars (~79 tok)
• tts: 223 chars (~56 tok)
• sessions_send: 203 chars (~51 tok)
• subagents: 179 chars (~45 tok)
• sessions_list: 176 chars (~44 tok)
• sessions_history: 149 chars (~38 tok)
• memory_search: 139 chars (~35 tok)
• memory_get: 128 chars (~32 tok)
• session_status: 89 chars (~23 tok)
• agents_list: 33 chars (~9 tok)
Top tools (summary text size):
• browser: 1,251 chars (~313 tok)
• memory_search: 334 chars (~84 tok)
• read: 298 chars (~75 tok)
• session_status: 207 chars (~52 tok)
• exec: 181 chars (~46 tok)
• web_search: 175 chars (~44 tok)
• tts: 152 chars (~38 tok)
• memory_get: 151 chars (~38 tok)
• sessions_spawn: 134 chars (~34 tok)
• message: 132 chars (~33 tok)
• edit: 129 chars (~33 tok)
• write: 127 chars (~32 tok)
• agents_list: 118 chars (~30 tok)
• nodes: 115 chars (~29 tok)
• canvas: 106 chars (~27 tok)
• subagents: 105 chars (~27 tok)
• process: 85 chars (~22 tok)
• sessions_send: 84 chars (~21 tok)
• sessions_list: 54 chars (~14 tok)
• sessions_history: 36 chars (~9 tok)
Tools (param count):
• message: 85 params
• nodes: 33 params
• browser: 28 params
• canvas: 18 params
• exec: 12 params
• process: 12 params
• sessions_spawn: 12 params
• edit: 6 params
• web_search: 6 params
• sessions_send: 5 params
• read: 4 params
• sessions_list: 4 params
• subagents: 4 params
• write: 3 params
• sessions_history: 3 params
• memory_search: 3 params
• memory_get: 3 params
• tts: 2 params
• session_status: 2 params
• agents_list: 0 params

#

Session tokens (cached): 186,667 total / ctx=1048576
Inline shortcut: a command token inside normal text (e.g. “hey /status”) that runs immediately (allowlisted senders only) and is stripped before the model sees the remaining message.

odd hawkBOT Feb 28, 2026, 12:27 PM

#

That /context detail is still showing cron + gateway missing, which means OpenClaw still thinks the current sender is not “owner” for that session (those two tools are owner-only and get stripped).

For Telegram, the owner mapping is just your Telegram user id (1359334095). Add it explicitly in config like this:

{
channels: {
telegram: {
enabled: true,
botToken: "...",

// make your Telegram DM identity explicit
dmPolicy: "allowlist",
allowFrom: ["tg:1359334095"],
},
},

#


commands: {
config: true,
restart: true,

// (important) declare who is the owner so owner-only tools exist
ownerAllowFrom: {
telegram: ["tg:1359334095"],
// alternatively: "*": ["tg:1359334095"]
},
},
}

Then restart the gateway and re-run /context detail in Telegram — you should see cron and gateway appear in the Tools list.

#

If they still don’t show up after that, it’s almost certainly the known “senderIsOwner not forwarded into embedded runs” regression (strips cron/gateway even though you’re authorized). The fix is in PR #22296; upgrading to the latest release should pick it up: https://github.com/openclaw/openclaw/pull/22296. If latest still reproduces, please file a GitHub issue with your /context detail tool list + version.

#

Yep — that /context detail confirms the problem is still: cron + gateway are being stripped from the agent toolset (everything else is present).

Two important clarifications:

It’s not your tools config. If tool policy was blocking, you’d be missing lots more than just those two. cron + gateway are treated as owner-only tools, so when senderIsOwner ends up false/undefined, OpenClaw removes them entirely.
Don’t add ownerAllowFrom. I mentioned an ownerAllowFrom-style key earlier, but it’s not in the public config schema (and OpenClaw config is strictly validated — unknown keys can prevent the gateway from starting). So please don’t paste that into openclaw.json.

What to do (Telegram)

Make sure your Telegram DM allowlist is explicit (this part is correct and schema-valid):

{
channels: {
telegram: {
dmPolicy: "allowlist",

#

allowFrom: ["tg:1359334095"], // your /whoami id
},
},
}

Docs: https://docs.openclaw.ai/channels/telegram

If it’s still missing after that (your case)

This matches a known regression where queued/followup (embedded) runs don’t get senderIsOwner forwarded, so owner-only tools (cron, gateway) get stripped even for the real owner. Fix is in PR #22296:
https://github.com/openclaw/openclaw/pull/22296

If you’re on 2026.2.26 and still hit it, the pragmatic workaround is to jump channels until the fix is promoted to stable:

#

openclaw update --channel beta
openclaw doctor
openclaw gateway restart

(or --channel dev if beta still doesn’t have it)

Docs:

Updating: https://docs.openclaw.ai/install/updating
Dev channels: https://docs.openclaw.ai/install/development-channels

If you want, paste openclaw --version after switching to beta, and the Telegram /context detail “Tools:” line again — we can confirm in one glance whether cron/gateway are back.

fallen eagle Feb 28, 2026, 12:38 PM

#

Alright! I found this PR which I think explains our issue?

https://github.com/openclaw/openclaw/pull/26331

But to add the commands.ownerAllowFrom, I get this error

openclaw-gateway-1 | - commands.ownerAllowFrom: Invalid input: expected array, received object

How should I convert this to the expected format

"ownerAllowFrom": { telegram: ["tg:1359334095"] }

odd hawkBOT Feb 28, 2026, 12:39 PM

#

That error is telling you the schema for commands.ownerAllowFrom is an array, not a per-channel map.

So instead of this (object → rejected):

ownerAllowFrom: { telegram: ["tg:1359334095"] }

use this (array → valid):

commands: {
ownerAllowFrom: ["tg:1359334095"], // your Telegram /whoami id
}

Notes:

commands.allowFrom is the one that takes an object like { telegram: [...] } (it’s command/directive authorization).

#

commands.ownerAllowFrom is just “who counts as owner” for owner-only tools (cron, gateway, whatsapp_login), so it’s a plain list.

Also: that PR you linked (#26331) is specifically fixing the “single-user but senderIsOwner=false when ownerAllowFrom is unset” bug. Once you’re on a release that includes it, you should be able to remove commands.ownerAllowFrom entirely and still get cron/gateway as long as you’re an authorized sender.

After changing config, restart the gateway and re-run /context detail — you should see cron and gateway show up in the Tools list.

fallen eagle Feb 28, 2026, 12:47 PM

#

Alright krill. I guess that resolved the issue. The agent can now access the missing tools. Although I would like to point out that they are still not listed in the context detail command. I guess that needs fixing.

Thanks Krill. love it.

odd hawkBOT Feb 28, 2026, 12:47 PM

#

Nice — glad it’s unblocked.

On the “still not listed in /context detail” bit: if the agent can successfully call cron / gateway, then the tools are effectively available and it’s likely just a display/inspection mismatch (the context inspector is showing the “base tool registry” but not the extra owner-only tool injection / filtering state, or it’s caching the old snapshot).

Two quick sanity checks:

Run /context detail again after a gateway restart (and ideally in a fresh DM/thread), and see if it updates.
Try a trivial tool call (e.g. ask the agent to “list cron jobs”) and confirm it works reliably.

If it continues to be missing from /context detail while still working, that’s a legit small bug / docs mismatch — worth a GitHub issue with:

openclaw --version
the /context detail Tools line
“cron tool call works, but context detail doesn’t list it”

Issue tracker: https://github.com/openclaw/openclaw/issues

If this fixed it for you, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

#Agent can't access tools for config and cron after updating to the latest versions.