discord tool not available | Friends of the Crustacean 🦞🤝 | Page 1

little cove Apr 15, 2026, 1:42 PM

#

My openclaw agent said "In this session, that message tool is not exposed, so I can’t invoke Discord channel actions from here even though the skill exists and Discord is configured.", but the agent is able to create discord channel before, why?

sharp mauveBOT Apr 15, 2026, 1:45 PM

#

Short answer: because tool exposure is not global or sticky, it is resolved per session/run.

So, “it created a Discord channel before” only proves that the earlier session had the message tool available. The current one may not.

Most common reasons:

it routed to a different agent or a thread-bound subagent/ACP session
message got filtered out by tool policy:
- tools.profile
- tools.allow / tools.deny
- tools.byProvider
- agents.list[].tools.*
- sandbox/subagent/group-specific overrides
the allowlist uses the wrong tool name. For Discord channel actions, the tool is message or group:messaging, not discord.message
some isolated runs intentionally disable message

A key detail from the docs: runtime tool availability is session-scoped, so even the same agent can show different tools in different sessions.

#

Docs:

Tools overview: https://docs.openclaw.ai/tools
Tool filtering order: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated
Discord channel actions use the shared message tool: https://docs.openclaw.ai/channels/discord

First things I’d check:

openclaw --version
In Control UI, open Agents → Tools → Available Right Now for the exact thread/session
Check whether your config allowlist includes message or group:messaging
If this is a Discord thread, confirm it is not currently bound to a different session/subagent

If you paste your openclaw --version plus the relevant tools / agents.list[].tools config, I can help pinpoint the exact reason.

little cove Apr 15, 2026, 1:48 PM

#

I see this section from openclaw.json

"tools": {
"profile": "coding",
"web": {
"search": {
"enabled": true,
"provider": "brave"
}
}
},

is this causing the issue? Should I set the profile to "full"?

sharp mauveBOT Apr 15, 2026, 1:49 PM

#

Yep, that can absolutely be the cause.

"tools.profile": "coding" does not include the message tool.

From the docs, coding includes things like fs/runtime/web/sessions/media, but not group:messaging. So if nothing else adds message back, the agent will say it is not exposed.

I would not switch straight to "full" unless you really want everything. Safer fix is to keep coding and explicitly allow messaging:

{
  tools: {
    profile: "coding",
    allow: ["group:messaging"],
    web: {
      search: {
        enabled: true,

#

        provider: "brave",
      },
    },
  },
}

Or equivalently:

{
  tools: {
    profile: "coding",
    allow: ["message"],
  },

#

A couple gotchas:

deny still wins over allow
agents.list[].tools.profile overrides the global profile for that agent
if this thread is routed to a different agent/subagent, that agent’s tool policy is what matters

So, short version:

Yes, profile: "coding" is likely why
No, you probably do not need full
best fix is allow: ["group:messaging"]

Docs:

#

If you want, paste your full tools block plus any agents.list[].tools section and I’ll sanity check it.

little cove Apr 15, 2026, 1:50 PM

#

why current profile set to "coding"? Is it a default? What is the vanilla default on first install opencloaw

sharp mauveBOT Apr 15, 2026, 1:50 PM

#

Yes, coding is now the local onboarding default for new configs.

Small nuance though:

Config semantics: if tools.profile is unset, that behaves like full
Onboarding behavior: for new local installs/configs, onboarding now writes tools.profile: "coding" by default

So the vanilla answer is:

fresh local install via current onboarding: usually gets "coding"
older config / manually edited config / unset profile: effectively full

That’s why you’re seeing it.

Docs say exactly this:

full = “No restriction (same as unset)”
local onboarding defaults new configs to tools.profile: "coding" when unset

#

Refs:

If your goal is just Discord channel actions, I still wouldn’t jump to full first. Better:

{
  tools: {
    profile: "coding",
    allow: ["group:messaging"],
  },
}

That keeps the safer default and just adds the message tool.

little cove Apr 15, 2026, 2:09 PM

#

I have added the "allow" node and restarted gateway, but the bot still said blocked

sharp mauveBOT Apr 15, 2026, 2:10 PM

#

If it still says blocked after restart, then the new allow is probably not the policy this run is actually using.

Most likely culprits:

Wrong tool name
Use one of these:

tools: {
  profile: "coding",
  allow: ["group:messaging"],
}

or

tools: {
  profile: "coding",

#

     allow: ["message"],
   }

Not discord.message, not discord.

Agent-level override
If the active agent has:
```
agents.list[].tools.profile
agents.list[].tools.allow
agents.list[].tools.deny
```
that can override the global tools block.
Deny still wins
Any deny anywhere in the chain will still block it.

#

Provider/group/subagent override
tools.byProvider, agent provider overrides, sandbox/subagent policy, or a bound thread/subagent can all change the effective tools.
You edited the wrong config scope
For example, global tools.allow won’t help if this Discord thread is routed to another agent with its own tool policy.

What I’d check next:

openclaw --version
paste the exact:
- top-level tools block
- active agents.list[] entry for this bot
- any tools.byProvider
in Control UI, open Agents → Tools → Available Right Now for this exact thread/session and see if message is listed

If you want, paste those config bits here and I’ll tell you exactly which line is still blocking it.

little cove Apr 15, 2026, 4:01 PM

#

I have just set the profile to "full", and it works, what's the downside of setting to "full", any major risks?

sharp mauveBOT Apr 15, 2026, 4:02 PM

#

The downside of full is basically bigger blast radius.

It means “no tool-profile restriction”, so the agent can see/use a much broader tool set if those tools are otherwise configured.

Main risks:

More prompt-injection exposure
If the agent reads untrusted content, web pages, docs, pasted text, etc., there are more tools it could be tricked into using.
More host/file/runtime access
full can expose filesystem/runtime/browser/messaging tools that coding or messaging would keep narrower.
Higher risk in shared/group chats
This is the big one. In open or multi-user rooms, broader tools are a much worse idea.
Plugin/extension tools may become reachable too
Permissive policy can expose more than just the built-ins.

#

A couple of important nuances:

full does not automatically bypass approvals
it does not automatically make everything unsafe by itself
for a private personal setup, it may be totally fine if you trust the inputs and keep sandboxing/approvals sane

My recommendation:

if this is your own private bot, full is not inherently crazy
if you want the safer fix, go back to:
```
tools: {
  profile: "coding",
  allow: ["group:messaging"],
}
```
That gives you Discord channel actions without broadening everything else.

#

Docs:

Rule of thumb: full is okay for trusted personal use, not great for shared/untrusted contexts.

quasi field Apr 16, 2026, 7:06 PM

#

Does Full automatically include/enable all tools? Then does allow inject group:messaging tool to openclaw on load? I don’t have any agent tool override or hooks to block messaging tool but setting profile to coding and allowing messaging will not get the openclaw to load messaging tool. Is this a potentially a bug?

sharp mauveBOT Apr 16, 2026, 7:07 PM

#

I think this is probably not a bug. The key detail is:

full = no profile restriction, same as unset
allow is restrictive, not additive
alsoAllow is the additive one

So this:

tools: {
  profile: "coding",
  allow: ["group:messaging"],
}

does not mean “coding plus messaging”.

#

It means “after profile filtering, apply an allowlist”. In practice, allow is for only these tools, not “inject this extra tool”.

If you want coding + message, the correct config is:

tools: {
  profile: "coding",
  alsoAllow: ["group:messaging"],
}

or

tools: {
  profile: "coding",

#

  alsoAllow: ["message"],
}

A couple of nuances:

full does not magically enable tools that are unavailable for runtime/provider/config reasons
deny still wins
you cannot use allow and alsoAllow together in the same scope

So yes, your observation makes sense:

full works
coding + allow does not add messaging
coding + alsoAllow is the intended shape

If coding + alsoAllow: ["group:messaging"] still fails, then that starts to smell like a real bug.

#

Docs:

If you want, paste the exact tools block you ended up with and I’ll sanity check it.

quasi field Apr 16, 2026, 7:09 PM

#

I also tried setting it to messaging(or messanger idr) profile. Does that not have the group:messaging tool included? I was trying to get my agent to send me a file from workspace, but it was saying it doesnt have messaging tool.

sharp mauveBOT Apr 16, 2026, 7:11 PM

#

messaging does include group:messaging, and group:messaging maps to the message tool.

So on paper:

tools: {
  profile: "messaging",
}

should expose message.

But there’s an important catch for your use case:

If you want the agent to send a file from the workspace, messaging alone is usually not enough, because it does not include filesystem tools like read.

So the agent may still fail that task, even though the messaging tool should be present.

#

Practical rule:

messaging = good for chat/send/session tools
coding = good for fs/runtime/web/session tools
“send a workspace file” usually wants both

Best fit is:

tools: {
  profile: "coding",
  alsoAllow: ["group:messaging"],
}

A few checks:

#discord tool not available