Summary

Discord slash sessions can fail elevated permission resolution even when tools.elevated.allowFrom.discord is configured correctly.

In the same setup, openclaw sandbox explain --session agent:main:discord:slash:<userId> can also misdiagnose the session as channel: (unknown), which sends debugging in the wrong direction.

This looks like the Discord counterpart of the already-reported Telegram slash/channel-unknown class of bug (for reference: #51245), but it affects elevated gating and sandbox explain output for Discord slash sessions.

Version

• OpenClaw 2026.3.23-2

Expected behavior

For a Discord slash session such as:

• agent:main:discord:slash:957519555150901298

OpenClaw should:

1. Resolve the session provider/channel as discord
2. Apply tools.elevated.allowFrom.discord
3. Report the same provider/channel correctly in openclaw sandbox explain

Actual behavior

Even with the config set, Discord slash elevated access still fails with:

elevated is not available right now (runtime=direct).
Failing gates: allowFrom
Fix-it keys:
- tools.elevated.enabled
- tools.elevated.allowFrom.<provider>
- agents.list[].tools.elevated.enabled
- agents.list[].tools.elevated.allowFrom.<provider>

And sandbox explain shows:

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

Relevant config

{
  "tools": {
    "elevated": {
      "enabled": true,
      "allowFrom": {
        "discord": ["957519555150901298"]
      }
    }
  },
  "commands": {
    "allowFrom": {
      "discord": ["957519555150901298"]
    }
  }
}

Reproduction

1. Configure:
   • tools.elevated.enabled = true
   • tools.elevated.allowFrom.discord = ["<discord-user-id>"]
   • commands.allowFrom.discord = ["<discord-user-id>"]
2. Trigger a Discord slash session
3. Request an elevated exec from that slash session
4. Run:

openclaw sandbox explain --session agent:main:discord:slash:<discord-user-id>

Observed diagnosis mismatch

The main runtime bug appears to be that the elevated permission resolution path does not always receive the Discord provider for slash sessions.

Separately, sandbox explain appears to have its own channel/provider inference gap for session keys of the form:

• agent:main:discord:slash:<userId>

So there seem to be two related issues:

1. Runtime gating bug: provider/channel is missing in elevated permission resolution for Discord slash sessions
2. Diagnostics bug: sandbox explain reports channel: (unknown) for the same session type

Local hotfix that restored behavior

A local hot patch restored expected behavior by adding a fallback that infers the provider/channel from SessionKey when provider metadata is missing, e.g. detecting :discord: in:

• ctx.SessionKey in the runtime permission path
• --session agent:main:discord:slash:<userId> in sandbox explain

After that patch, sandbox explain changed from:

channel: (unknown)
allowedByConfig: false

to:

channel: discord
allowedByConfig: true

Why this matters

This is easy to misdiagnose as a user config mistake, because the fix-it hints point at allowFrom keys even though the configured values are already present.

So the bug has two user-visible effects:

• elevated slash flows do not work on Discord
• diagnostics suggest the wrong root cause