Tools Allowlist not recognizing group:sessions | Friends of the Crustacean 🦞🤝 | Page 1

onyx heart Apr 16, 2026, 12:04 AM

#

Below is a structure from my config:

"list": [ { "id": "main", "default": true, "name": "C.O.R.T.E.X", "workspace": "/home/node/.openclaw/workspace", "agentDir": "/home/node/.openclaw/agents/main/agent", "model": { "primary": "groq/meta-llama/llama-4-scout-17b-16e-instruct" }, "subagents": { "allowAgents": ["*"] }, "tools": { "profile": "messaging", "deny": ["canvas", "browser", "exec"], "elevated": { "enabled": true }, "allow": ["group:sessions"] } },

I'm seeing the following warnings when I restart the gateway:

9:42:24 AM info gateway/ws webchat connected conn=81cfdbc3-0488-472b-855c-b745ee8d276c remote=10.42.2.222 client=openclaw-control-ui webchat v2026.4.14 9:42:59 AM warn tools tools.profile (messaging) allowlist contains unknown entries (edit). These entries are shipped core tools but unavailable in the current runtime/provider/model/config. 9:42:59 AM warn tools agents.main.tools.allow allowlist contains unknown entries (group:sessions). These entries won't match any tool unless the plugin is enabled. 9:48:49 AM info gateway/ws webchat disconnected code=1001 reason=n/a conn=81cfdbc3-0488-472b-855c-b745ee8d276c

Not sure what is going wrong here? why is it not recognizing group:sessions?

#

The only change I made was to change

            "accounts": {
              "default": {
                "token": "{{ .OPENCLAW_DISCORD_BOT_TOKEN }}",
                "guilds": {
                  "{{ .DISCORD_SERVER_ID }}": {
                    "channels": {
                      "{{ .DISCORD_CHANNEL_ID }}": { "enabled": true, "requireMention": true, "users": [ "{{ .MY_DISCORD_USERID }}" ] },
                      "{{ .DISCORD_GENERAL_CHANNEL_ID }}": { "enabled": true, "requireMention": false }
                    }
                  }
                }
              },

Got change to "requireMention": false, for each of the agents.

mortal trenchBOT Apr 16, 2026, 12:08 AM

#

group:sessions is valid on current OpenClaw builds. The warning text is a bit misleading.

A few key points:

tools.profile: "messaging" already includes:
- sessions_list
- sessions_history
- sessions_send
- session_status
So your extra:
```
"allow": ["group:sessions"]
```
is really only trying to add:
- sessions_spawn
- sessions_yield

#

subagents
The "unless the plugin is enabled" part is generic warning text. It does not mean group:sessions is a plugin. It just means “this allowlist entry didn’t match the active tool inventory”.

What that usually means is one of these:

Version skew / older build
That agent runtime is not registering session tools
Bug in that release

Also, this bit is a clue:

tools.profile (messaging) allowlist contains unknown entries (edit)

That usually means you have a tools.fs block somewhere else in config. Current source treats an explicit tools.fs config as a filesystem opt-in and adds read/write/edit on top of messaging.

#

What I’d try next

First, paste:

openclaw --version

Then, as a quick workaround/test, replace:

"allow": ["group:sessions"]

with:

#

"allow": ["sessions_spawn", "sessions_yield", "subagents"]

If those still warn, then it’s not the group alias, it’s that those tools are not being registered at all in your runtime.

If you only need list/history/send/status, you can remove group:sessions entirely, because messaging already gives those.

Docs:

If you paste openclaw --version and your full tools block, I can narrow it down pretty quickly.

onyx heart Apr 16, 2026, 12:08 AM

#

Since then it does not recognize group:sessions

mortal trenchBOT Apr 16, 2026, 12:09 AM

#

Yep, that requireMention: false change is not the cause.

That setting only changes Discord channel reply gating. It does not affect tool registration or tools.allow. Docs here: https://docs.openclaw.ai/channels/discord

So what likely happened is:

you restarted the gateway because of the Discord config change
startup/tool-resolution ran again
it surfaced a pre-existing tool policy/runtime mismatch

A few concrete notes:

group:sessions is a real built-in group on current builds, not a plugin.
The warning text saying unless the plugin is enabled is generic/misleading here.
With profile: "messaging", you already get:
- sessions_list
- sessions_history

#

sessions_send
- session_status

So your extra:

"allow": ["group:sessions"]

is really only trying to add:

sessions_spawn
sessions_yield
subagents

If that group is warning, it usually means those tools are not present in the active runtime/tool inventory for that agent.

#

Also, this warning is another clue:

tools.profile (messaging) allowlist contains unknown entries (edit)

That usually means there is also a tools.fs block somewhere else in your config. An explicit tools.fs config can re-expose read/write/edit even under messaging.

Next thing I’d check

Please paste:

openclaw --version

And as a quick test, try replacing:

#

"allow": ["group:sessions"]

with:

"allow": ["sessions_spawn", "sessions_yield", "subagents"]

If those also warn, then it’s not the group alias, it’s that those tools are not being registered at all on your build/runtime.

If you want, paste the full tools block plus openclaw --version and I can narrow it down fast.

#

I get why it looks connected, but I really don’t think the requireMention change caused this.

They’re separate config paths:

channels.discord...requireMention controls whether Discord messages need an @mention
agents.list[].tools.allow controls which tools the agent can use

So the more likely story is:

you changed requireMention
restarted
the restart re-ran tool resolution
that exposed an existing tool/runtime mismatch

Two useful clues from your logs:

group:sessions is being treated as “didn’t match the active tool set”

#

messaging is also complaining about edit, which strongly suggests there’s probably a tools.fs block elsewhere in config

So I’d check these next:

openclaw --version
whether you have any tools.fs config anywhere
whether explicit tools work better than the group alias:

"allow": ["sessions_spawn", "sessions_yield", "subagents"]

If those explicit names also warn, then the issue is not group:sessions, it’s that those session tools are not being registered on your current build/runtime.

If you paste:

openclaw --version
your full tools block

#

and whether you have a tools.fs section

I can probably pinpoint it.

onyx heart Apr 16, 2026, 12:12 AM

#

node@openclaw-xunholy-75c59cb5db-rvc2m:/app$ openclaw --version
OpenClaw 2026.4.14

Let me try replacing the group:sessions with what you recommended and restart the gateway.
I'll be right back.

mortal trenchBOT Apr 16, 2026, 12:12 AM

#

Perfect, that helps.

On 2026.4.14, group:sessions should be valid, so this is looking more like either:

a group alias bug, if the explicit tool names work, or
a session-tool registration/runtime issue, if the explicit names also warn

When you’re back, the key thing to check is whether the warnings change to something like:

no warning at all, or
unknown entries for sessions_spawn / sessions_yield / subagents

If those individual names still warn, paste the new log and I’ll help narrow it down.

onyx heart Apr 16, 2026, 12:17 AM

#

Ok. Changed config and not seeing that warning anymore.
What's the best way to confirm that the sessions tools are working on the main agent?

mortal trenchBOT Apr 16, 2026, 12:18 AM

#

Nice, that’s a good sign.

Best way to confirm is to test the tools themselves, not slash commands like /status (that hits command handling, not tool access).

I’d do these in order:

List visible sessions

Use sessions_list and show me the visible sessions.

Expected: at least the current session shows up.
Read current session status

Use session_status on the current session.

Expected: status card/details for this session.
Spawn a trivial child

#

Use sessions_spawn to start a subagent with the task: reply with only OK, then tell me the runId and childSessionKey.

Expected: you get a runId and child session key back.

Check subagent control

Use subagents with action=list and show me active/recent runs.

Expected: the spawned child appears there.
Read the child session

Use sessions_history on the child session you just spawned and summarize it.
Optional: send into the child

Use sessions_send to send ping to that child session and wait for the reply.

If all of those work, your main agent’s session tools are good.

#

Also, since explicit tool names worked but group:sessions didn’t, that really smells like a 2026.4.14 group-alias bug. If you want maintainer eyes on it, please file an issue here: https://github.com/openclaw/openclaw/issues

Glad we narrowed it down 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

onyx heart Apr 16, 2026, 12:21 AM

#

Damn, now I'm hitting API rate limits. I'll try testing it again later one the limit resets.

mortal trenchBOT Apr 16, 2026, 12:21 AM

#

Ah, that’s annoying.

Honestly, if the warning disappeared after switching from group:sessions to the explicit session tool names, that’s already a pretty strong signal the config is fine and the problem was the alias handling.

When your limit resets, I’d do the cheapest smoke test first:

Use sessions_list and show me the visible sessions.

If that works, then:

Use session_status on the current session.

Those are the lowest-friction checks before trying sessions_spawn.

So I’d call it:

likely fixed

#

probably a group:sessions alias bug on 2026.4.14
worth filing at https://github.com/openclaw/openclaw/issues when you get a minute

If you test later and anything weird shows up, drop the exact error here and I’ll help pick it apart.

onyx heart Apr 16, 2026, 2:02 AM

#

<final>I apologize, but I am unable to use the sessions_spawn tool as it is not found. Therefore, I cannot start a subagent as requested.</final>

mortal trenchBOT Apr 16, 2026, 2:03 AM

#

That ...sessions_spawn tool is not found... is the agent’s reply, not the actual runtime inventory.

Best next step: send this as a standalone message in that same conversation:

/tools verbose

That’s the real source of truth for “what this agent can use right now”. Docs: https://docs.openclaw.ai/tools/slash-commands

What to look for

You want to see these in /tools verbose:

sessions_list
sessions_history
sessions_send
session_status

#

sessions_spawn
sessions_yield
subagents

If `sessions_spawn` is missing

Then the agent still doesn’t actually have it at runtime, and I’d want to see the /tools verbose output.

If `sessions_spawn` is present

Then I’d do a fresh session reset and retry:

/new

Then ask something tiny like:

Use sessions_spawn to start a subagent that replies only OK, then tell me the runId.

#

So basically:

/tools verbose
If it’s there, /new
Retry the tiny sessions_spawn test

If you paste the /tools verbose output, I can tell you immediately whether the main agent really has the session tools or not.

onyx heart Apr 16, 2026, 2:06 AM

#

When I run /tools verbose I get this:

`[{provider}/{model}] No tools are available for this agent right now.

Profile: messaging`

#

Here is the json for the main agent:

          "list": [
            {
              "id": "main",
              "default": true,
              "name": "C.O.R.T.E.X",
              "workspace": "/home/node/.openclaw/workspace",
              "agentDir": "/home/node/.openclaw/agents/main/agent",
              "model": {
                "primary": "groq/meta-llama/llama-4-scout-17b-16e-instruct"
              },
              "subagents": { "allowAgents": ["*"] },
              "tools": {
                "profile": "messaging",
                "deny": ["canvas", "browser", "exec"],
                "elevated": { "enabled": true },
                "allow": ["sessions_spawn", "sessions_yield", "subagents"]
              }
            },

mortal trenchBOT Apr 16, 2026, 2:13 AM

#

Yeah, this looks like tool policy, not requireMention.

The big clue is this:

/tools verbose
[{provider}/{model}] No tools are available for this agent right now.

That means the agent’s effective tool inventory is empty before the model even tries anything.

What’s going on

There are probably two separate issues here:

allow is restrictive, not additive
tools.profile: "messaging" sets a base allowlist, then tools.allow filters again.

#

Current docs say messaging includes only:

message
sessions_list
sessions_history
sessions_send
session_status

It does not include:

sessions_spawn
sessions_yield
subagents

Docs: https://docs.openclaw.ai/gateway/configuration-reference#tool-profiles
Sessions docs: https://docs.openclaw.ai/concepts/session-tool

#

The edit warning strongly suggests you have a tools.fs config somewhere
messaging by itself does not include edit, so if you’re seeing:
```
tools.profile (messaging) allowlist contains unknown entries (edit)
```
then something else in config is implicitly surfacing FS tools.

Why `group:sessions` is acting weird

On current source/docs, group:sessions is valid.

So if your runtime warns that it’s unknown and /tools verbose is empty, the most likely explanations are:

version skew / older build
another global/provider/group tool policy is filtering everything out

#

a bug in the installed runtime’s allowlist handling

Best next checks

Please paste:

openclaw --version
your full top-level tools block
whether you have any of these anywhere:
- tools.fs
- tools.byProvider
- agents.defaults.tools
- group/channel-specific tool policy

Practical test config

For a clean test, I’d avoid both profile: "messaging" and group:sessions and use an explicit allowlist:

#

"tools": {
  "allow": [
    "message",
    "sessions_list",
    "sessions_history",
    "sessions_send",
    "sessions_spawn",
    "sessions_yield",
    "subagents",
    "session_status"
  ],
  "deny": ["canvas", "browser", "exec"]
}

Then restart and run /tools verbose again.

#

If that still shows no tools, it’s almost certainly not the alias, it’s the installed version/runtime policy path.

onyx heart Apr 16, 2026, 2:13 AM

#

@mortal trench is there a problem with the configuration?

#

the tools structure from the config:

        "tools": {
          "media": {
            "audio": {
              "enabled": true,
              "maxBytes": 20971520,
              "models": [{ "provider": "groq", "model": "whisper-large-v3" }]
            }
          },
          "sessions": {
            "visibility": "tree"
          },
          "sessions_spawn": {
            "attachments": {
              "enabled": false,
              "maxTotalBytes": 5242880,
              "maxFiles": 50,
              "maxFileBytes": 1048576,
              "retainOnSessionKeep": false
            }
          },

          "agentToAgent": {
            "enabled": true,
            "allow": ["main", "planner", "ideator", "critic", "surveyor", "coder", "writer", "reviewer", "scout"]
          },
          "media": {
            "audio": {
              "models": [{ "provider": "groq" }]
            }
          },
          "profile": "full",
          "sessions": {
            "visibility": "all"
          },
          "fs": {
            "workspaceOnly": true
          },
          "web": {
            "search": {
              "provider": "searxng"
            },
            "fetch": {
              "enabled": true
            }
          }
        },

mortal trenchBOT Apr 16, 2026, 2:17 AM

#

This makes a lot more sense now.

Short version

requireMention is not the cause.

What’s happening is:

agents.main.tools.allow is a hard filter
your only agent allow entry is group:sessions
on the runtime you’re actually running, that alias is being treated as unknown
so the allowlist matches nothing
that’s why /tools verbose shows:

No tools are available for this agent right now.

#

So the empty inventory is consistent with the warning.

Why the `edit` warning appears

This part of your top-level config is the clue:

"fs": {
  "workspaceOnly": true
}

Current source has special handling where a messaging profile plus tools.fs implicitly re-exposes:

read

#

write
edit

So this warning:

tools.profile (messaging) allowlist contains unknown entries (edit)

is very likely coming from that fs block, not from Discord settings.

Important nuance about `profile: "messaging"`

Even if group:sessions were recognized perfectly, profile: "messaging" only includes:

#

message
sessions_list
sessions_history
sessions_send
session_status

It does not include:

sessions_spawn
sessions_yield
subagents

So allow: ["group:sessions"] is also the wrong shape if your goal is to add spawn/subagent tools on top of messaging.

allow narrows. It does not add.

#

Best workaround right now

I’d avoid the alias entirely on this build and use explicit tool names.

If you want a messaging-ish agent with session tools, try:

"tools": {
  "profile": "messaging",
  "deny": ["canvas", "browser", "exec"],
  "allow": [
    "sessions_list",
    "sessions_history",
    "sessions_send",
    "session_status"
  ]

#

If you also want subagent spawning, then you need an additive path, not that allow filter. On current source that would be alsoAllow, or just use one explicit allowlist without relying on profile.

A clean test would be:

"tools": {
  "allow": [
    "message",
    "sessions_list",
    "sessions_history",
    "sessions_send",
    "sessions_spawn",

#

    "sessions_yield",
    "subagents",
    "session_status"
  ],
  "deny": ["canvas", "browser", "exec"]
}

Then restart and run /tools verbose again.

My actual diagnosis

group:sessions is valid in current docs/source
but your running build/runtime is behaving like it does not know that alias

#

because agents.main.tools.allow is restrictive, that one unknown entry collapses the effective inventory to zero

So this looks like version/runtime skew or an alias-handling bug, not a Discord channel config issue.

If you can, paste:

openclaw --version

That’ll tell us whether you’re on a build where this is just fixed already in source but not in your install.

onyx heart Apr 16, 2026, 2:21 AM

#

node@openclaw-xunholy-5c758845bc-hh9jm:/app$ openclaw --version
OpenClaw 2026.4.14

mortal trenchBOT Apr 16, 2026, 2:22 AM

#

Thanks, that nails it down.

I checked the actual v2026.4.14 tag, and on that tag:

src/agents/tool-catalog.ts does include group:sessions
src/agents/pi-tools.policy.test.ts also shows tools.fs on a messaging profile can implicitly surface read, write, edit

So on OpenClaw 2026.4.14, your warning is not expected. This looks like a real runtime/build bug, not a bad requireMention setting.

What the warnings mean

1) `group:sessions`

This part is the main breakage:

agents.main.tools.allow allowlist contains unknown entries (group:sessions)

#

Because agents.main.tools.allow is restrictive, once that single entry is treated as unknown, it matches nothing.

That is why /tools verbose ends up showing:

No tools are available for this agent right now.

2) `edit`

This one is explained by your global config:

"fs": {
  "workspaceOnly": true
}

#

With a messaging profile, that can implicitly re-expose FS tools, which is why you see the separate edit warning.

One more important nuance

Even if group:sessions were working, profile: "messaging" does not include:

sessions_spawn
sessions_yield
subagents

So allow: ["group:sessions"] is also not a good way to add those on top of messaging.

Best workaround on `2026.4.14`

Avoid the group alias on this release and use explicit tool names.

If you want only the messaging-profile session tools:

#

"tools": {
  "profile": "messaging",
  "deny": ["canvas", "browser", "exec"],
  "allow": [
    "sessions_list",
    "sessions_history",
    "sessions_send",
    "session_status"
  ]
}

If you also want spawning/subagents, use one explicit allowlist instead of relying on profile + group:sessions:

#

"tools": {
  "allow": [
    "message",
    "sessions_list",
    "sessions_history",
    "sessions_send",
    "sessions_spawn",
    "sessions_yield",
    "subagents",
    "session_status"
  ],
  "deny": ["canvas", "browser", "exec"]
}

Bottom line

#

Your config idea is reasonable.
group:sessions should be recognized on 2026.4.14, but your runtime is not treating it that way.

So I’d call it:

not caused by Discord requireMention
edit warning explained by global tools.fs
group:sessions behavior looks like a 2026.4.14 bug / bad runtime state

If the explicit-name workaround works, use that for now. If it still fails, please file a GitHub issue with:

openclaw --version
the two warning lines
/tools verbose output
the agent tools block

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

#

Glad we caught the real shape of it, this one was sneaky.

onyx heart Apr 16, 2026, 2:31 AM

#

Does this:

"tools": { "allow": [ "message", "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "sessions_yield", "subagents", "session_status" ], "deny": ["canvas", "browser", "exec"] }

need to be under agent.defaults.list or under tools ?

mortal trenchBOT Apr 16, 2026, 2:32 AM

#

Put that under the agent’s tools block, so in your case:

"agents": {
  "list": [
    {
      "id": "main",
      "default": true,
      "name": "C.O.R.T.E.X",
      "workspace": "/home/node/.openclaw/workspace",
      "agentDir": "/home/node/.openclaw/agents/main/agent",
      "model": {
        "primary": "groq/meta-llama/llama-4-scout-17b-16e-instruct"
      },
      "subagents": { "allowAgents": ["*"] },
      "tools": {

#

        "allow": [
          "message",
          "sessions_list",
          "sessions_history",
          "sessions_send",
          "sessions_spawn",
          "sessions_yield",
          "subagents",
          "session_status"
        ],
        "deny": ["canvas", "browser", "exec"]
      }
    }
  ]
}

#

Quick rule of thumb

tools at top level = applies globally
agents.defaults.tools = default for all agents
agents.list[].tools = just that one agent

So for only main / C.O.R.T.E.X, use agents.list[].tools.

Also, agents.defaults.list is not the right path.

And for this test, I’d remove the old:

"profile": "messaging",
"allow": ["group:sessions"]

#

from that same agent block, so you’re testing only the explicit allowlist.

After restart, run:

/tools verbose

You should see exactly that tool set.

onyx heart Apr 16, 2026, 2:53 AM

#

"list": [
{
"id": "main",
"default": true,
"name": "C.O.R.T.E.X",
"workspace": "/home/node/.openclaw/workspace",
"agentDir": "/home/node/.openclaw/agents/main/agent",
"model": {
"primary": "groq/meta-llama/llama-4-scout-17b-16e-instruct"
},
"subagents": { "allowAgents": ["*"] },
"tools": {
"deny": ["canvas", "browser", "exec"],
"elevated": { "enabled": true },
"allow": [
"message",
"sessions_list",
"sessions_history",
"sessions_send",
"sessions_spawn",
"sessions_yield",
"subagents",
"session_status"
]
}
},

mortal trenchBOT Apr 16, 2026, 2:53 AM

#

Yep, that placement looks right for main.

This version is much cleaner:

no profile: "messaging"
no group:sessions
explicit allow list only

So for tool policy, this is the right shape.

Next step

Restart the gateway, then run:

/tools verbose

#

What I’d expect now

You should see these tools available for that agent:

message
sessions_list
sessions_history
sessions_send
sessions_spawn
sessions_yield
subagents
session_status

And the old warnings about:

group:sessions
tools.profile (messaging) ... (edit)

#

should ideally be gone for main.

Small note

message is optional if you only care about normal in-thread replies, but it’s fine to keep if you want proactive sends/tool-driven messaging.

If you restart and /tools verbose still comes back empty, paste that output, because then we’re no longer looking at an alias issue, we’re looking at something deeper in the runtime.

onyx heart Apr 16, 2026, 2:54 AM

#

output of /tools verbose

[{provider}/{model}] Available tools

Profile: full
What this agent can use right now:

Built-in tools
Message - Send, delete, and manage messages via channel plugins. Supports actions: send, broadcast, read, edit, delete, search, channel-create, channel-edit, channel-delete, channel-move, category-create, category-edit, category-delete, react, reactions, download-file, upload-file, pin, unpin, list-pins, member-info,...
Session History - Fetch sanitized message history for a visible session. Supports limits and optional tool messages; use this to inspect another session before replying, debugging, or resuming work.
Session Send - Send a message into another visible session by sessionKey or label. Use this to delegate follow-up work to an existing session; waits for the target run and returns the updated assistant reply when available.
Session Status - Show a /status-equivalent session status card for the current or another visible session, including usage, time, cost when available, and linked background task context. Optional model sets a per-session model override; model=default resets overrides. Use this for questions like what model is active or how a...
Sessions (sessions_list) - List visible sessions with optional filters for kind, recent activity, and last messages. Use this to discover a target session before calling sessions_history or sessions_send.
Sessions (sessions_spawn) - Spawn an isolated session with runtime="subagent" or runtime="acp". mode="run" is one-shot and mode="session" is persistent or thread-bound. Subagents inherit the parent workspace directory automatically. Use this when the work should happen in a fresh child session instead of the current one.
Subagents - List, kill, or steer spawned sub-agents for this requester session. Use this for sub-agent orchestration.
Yield - End your current turn. Use after spawning subagents to receive their results as the next message.

mortal trenchBOT Apr 16, 2026, 2:54 AM

#

Nice, that’s the result we wanted.

This means the explicit allowlist workaround is working. The agent now clearly has:

message
sessions_list
sessions_history
sessions_send
sessions_spawn
sessions_yield
subagents
session_status

Why it says `Profile: full`

That part is normal now.

You removed profile: "messaging", so /tools verbose falls back to showing:

#

Profile: full

That does not mean all tools are available.
The real source of truth is the actual tool list shown underneath, and that list is correctly narrowed to your explicit allow.

So the diagnosis is basically confirmed

The problem was with the old policy shape, specifically:

profile: "messaging" plus
allow: ["group:sessions"]

Your new explicit allow list avoids that bug/path entirely.

Next real smoke test

I’d try these in order:

#

sessions_list
session_status
sessions_spawn with a tiny task like “reply only OK”

If those work, then you’re good.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

onyx heart Apr 16, 2026, 2:54 AM

#

Yet when I tell it "Use sessions_spawn to start a subagent with the task: reply with only OK, then tell me the runId and childSessionKey" like you mentioned it cannot find the sessions tools?

mortal trenchBOT Apr 16, 2026, 2:55 AM

#

Yep, that means we’re past the allowlist problem now.

Since /tools verbose shows sessions_spawn, sessions_list, etc, the tools are available.

So if the agent still says “I can’t find the sessions tools”, that’s now usually one of these:

stale conversation context from earlier failures
the model isn’t reliably calling tools, and is saying that in plain text instead of actually trying

Best next test

Do this in a fresh session first:

/new

#

Then test the tools in increasing order:

Use sessions_list and show me the result.
Use session_status on the current session.
Use sessions_spawn to start a subagent with task: reply only OK.

That’s better than jumping straight to the full runId + childSessionKey prompt.

Why I’d try `/new`

Earlier in this thread the agent genuinely had no tools, so it may just be carrying that bad context forward. A fresh session removes that variable.

Important distinction

If the assistant replies with something like:

“I can’t find sessions_spawn”

that is often just the model talking.

#

If the gateway/runtime is actually failing, you’d want to look for a real tool/runtime error in logs, like an actual Tool ... not found style message.

If it still fails after `/new`

Paste:

the exact assistant reply
and any matching gateway log lines

If sessions_list works in a fresh session but sessions_spawn fails, that points much more toward model/tool-use reliability than config.

If you want, I can help you narrow that down next.

onyx heart Apr 16, 2026, 2:55 AM

#

<final>I still cannot use the sessions_spawn tool, David, as it is not found in my available tools. I am unable to start a subagent as requested.</final>[{provider}/{model}] No tools are available for this agent right now.

Profile: messaging

mortal trenchBOT Apr 16, 2026, 2:56 AM

#

Ah, that’s actually a really useful clue.

The key line is:

Profile: messaging

If your new explicit allowlist were the one actually in effect, /tools verbose would be showing Profile: full with the session tools listed, like it did before.

So this failing run is still seeing the old config/policy snapshot, not the new one.

What that means

This is probably one of these:

the gateway is still loading the old config

#

there’s a second main agent entry or duplicate tools block
you edited one config file, but the gateway is reading a different file
the gateway/webchat session is stale and needs a real restart + fresh session

Best next checks

Run /tools verbose as a standalone message again
in the exact same thread where it failed.

If it says:
```
Profile: messaging
```
then the new config is definitely not what this session is using.

#

Search your actual loaded config for leftover old entries:
- profile: "messaging"
- group:sessions
- duplicate "id": "main"
- duplicate "tools" blocks in the same agent object
Restart the actual gateway, not just the web UI:
```
openclaw gateway restart
```
Then in chat:
```
/new
```
and after that:

#

   /tools verbose

The smoking gun

Your two results contradict each other:

earlier: Profile: full + session tools visible
now: Profile: messaging + no tools

That usually means different config state, not “sessions_spawn is broken”.

If you want, paste the full main agent block exactly as it exists now, because I’m a little worried there’s a duplicate/old tools section still hanging around.

onyx heart Apr 16, 2026, 3:02 AM

#

Thank you for the help.

Did these in order and now working after /new session was set.

List visible sessions
Use sessions_list and show me the visible sessions.

Expected: at least the current session shows up.

Read current session status
Use session_status on the current session.

Expected: status card/details for this session.

Spawn a trivial child
Use sessions_spawn to start a subagent with the task: reply with only OK, then tell me the runId and childSessionKey.

Expected: you get a runId and child session key back.

Check subagent control
Use subagents with action=list and show me active/recent runs.

Expected: the spawned child appears there.

Read the child session
Use sessions_history on the child session you just spawned and summarize it.

Optional: send into the child
Use sessions_send to send ping to that child session and wait for the reply.

#Tools Allowlist not recognizing group:sessions

What I’d try next

Next thing I’d check

What to look for

If sessions_spawn is missing

If sessions_spawn is present

What’s going on

Why group:sessions is acting weird

Best next checks

Practical test config

Short version

Why the edit warning appears

Important nuance about profile: "messaging"

Best workaround right now

My actual diagnosis

What the warnings mean

1) group:sessions

2) edit

One more important nuance

Best workaround on 2026.4.14

Bottom line

Quick rule of thumb

Next step

What I’d expect now

Small note

Why it says Profile: full

So the diagnosis is basically confirmed

Next real smoke test

Best next test

Why I’d try /new

Important distinction

If it still fails after /new

What that means

Best next checks

The smoking gun

If `sessions_spawn` is missing

If `sessions_spawn` is present

Why `group:sessions` is acting weird

Why the `edit` warning appears

Important nuance about `profile: "messaging"`

1) `group:sessions`

2) `edit`

Best workaround on `2026.4.14`

Why it says `Profile: full`

Why I’d try `/new`

If it still fails after `/new`