#elevated is not available right now

1 messages · Page 1 of 1 (latest)

burnt fableBOT
#

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

proper wagonBOT
#

That error means your message tried to run exec in elevated mode, but elevated is currently not authorized for Telegram senders.

In OpenClaw, elevated has its own allowlist:

  • global gate: tools.elevated.enabled
  • sender gate: tools.elevated.allowFrom.telegram ← this is the one you’re failing
  • optional per-agent gates: agents.list[].tools.elevated.* (can further restrict)

Docs: https://docs.openclaw.ai/tools/elevated (and background: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated)

Fix (config)

Add your numeric Telegram user id to the elevated allowlist (I strongly recommend keeping this tight—just you):

{
  tools: {
# 
    elevated: {
      enabled: true,
      allowFrom: {
        telegram: [
          "8119960887", // <-- your Telegram user id (quote it to avoid bigint issues)
        ],
      },
    },
  },

  // ONLY if you also set per-agent restrictions; otherwise omit:
  // agents: {
  //   list: [{
  //     id: "main",
  //     tools: { elevated: { enabled: true, allowFrom: { telegram: ["8119960887"] } } },
#
  1. openclaw --version
  2. openclaw sandbox explain --session agent:main:telegram:direct:8119960887
hollow lintel
#

now it returns this:

⚙️ bash: echo helloooo
Exit: 0

Approval required (id c1483874). Approve to run; updates will arrive after completion.

i want no approve need

proper wagonBOT
#

If you want zero prompts, you need to switch exec into “auto-approve” mode.

Fast (per-session, from Telegram)

Send this as a standalone message in the same Telegram DM:

/elevated full

full = run on host and skip exec approvals for that session.
To go back to prompts later:

/elevated ask

Docs: https://docs.openclaw.ai/tools/elevated

#

For the approval that’s already pending

You can also approve that one from chat:

/approve c1483874 allow-once

(or allow-always)

Docs: https://docs.openclaw.ai/tools/exec-approvals

If you want it default-no-prompts (dangerous)

You can make new sessions default to full elevated, but that’s basically “Telegram can run host commands without interlocks”, so only do this if your Telegram access is locked down:

{
# 
  agents: {
    defaults: {
      elevatedDefault: "full",
    },
  },
}

If you tell me whether your exec is happening on the Gateway or a Node, I can point you to the exact place in Control UI (“Nodes → Exec approvals”) to disable prompts there too.

hollow lintel
#

i updated my config, the issue stays.
the exec should happen on the gaeway.

proper wagonBOT
#

If you updated config and you’re still failing allowFrom (tools.elevated.allowFrom.telegram), 99% of the time it’s one of these:

  1. You edited a different config file than the gateway service is actually running with
  2. The allowlist entry doesn’t match the sender identity OpenClaw is using for Telegram
  3. You have a per-agent elevated allowFrom set that’s more restrictive (so you must match both)

Since you said exec should happen on the gateway, here’s the quickest way to pinpoint which one:

1) Confirm the gateway is using the config you edited

Run on the gateway host:

openclaw --version
openclaw gateway status

In openclaw gateway status, look for the Config (service) path and make sure that’s the file you edited. If you changed config, also do:

# 
openclaw gateway restart

2) Verify what the gateway thinks your elevated allowFrom is

openclaw config get tools.elevated.enabled
openclaw config get tools.elevated.allowFrom.telegram

If that prints null/empty, you’re not editing the right config (or it didn’t reload).

3) Verify the Telegram sender id you should allowlist

DM the bot once, then:

# 
openclaw logs --follow

Find the incoming Telegram message and copy from.id.

Then set (in config) exactly that id. If you want to be extra explicit, use the prefix form the docs mention:

tools: {
  elevated: {
    enabled: true,
    allowFrom: {
      telegram: ["id:8119960887"], // use your real from.id
    },
  },
# 
}

4) Check if per-agent config is blocking it

Run what the error suggests (quote it so your shell doesn’t expand *):

openclaw sandbox explain --session 'agent:main:telegram:direct:*'

That output will show whether agents.list[].tools.elevated.allowFrom.telegram is set and causing the mismatch.

If you paste the outputs of (gateway status) + (config get allowFrom) + (sandbox explain) (redact tokens), I can tell you exactly which gate is still failing and why.

hollow lintel
#

output of `openclaw sandbox explain --session 'agent:main:telegram:direct:*'


🦞 OpenClaw 2026.3.2 (unknown)
   Open source means you can see exactly how I judge your config.

│
◇  Doctor warnings ──────────────────────────────────────────────────────────╮
│                                                                            │
│  - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and    │
│    allowFrom) is empty — all group messages will be silently dropped. Add  │
│    sender IDs to channels.telegram.groupAllowFrom or                       │
│    channels.telegram.allowFrom, or set groupPolicy to "open".              │
│                                                                            │
├────────────────────────────────────────────────────────────────────────────╯
Effective sandbox:
  agentId: main
  sessionKey: agent:main:telegram:direct:*
  mainSessionKey: agent:main:main
  runtime: direct
  mode: off scope: agent perSession: false
  workspaceAccess: none workspaceRoot: /home/dariusclaws/.openclaw/sandboxes

Sandbox tool policy:
  allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
  deny  (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

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

Fix-it:
  - tools.sandbox.tools.allow
  - tools.sandbox.tools.deny
  - agents.list[].tools.sandbox.tools.allow
  - agents.list[].tools.sandbox.tools.deny
  - tools.elevated.enabled

Docs: docs.openclaw.ai/sandbox
proper wagonBOT
#

That sandbox explain output is the key clue:

  • sessionKey: agent:main:telegram:direct:*
  • channel: (unknown)
  • allowedByConfig: false

The * is not a real session key, so OpenClaw can’t resolve the channel → it can’t evaluate tools.elevated.allowFrom.telegram correctly, and it falls back to “unknown / not allowed”.

Do this instead (use the real session key)

  1. On the gateway, tail logs:
openclaw logs --follow

  1. Send a Telegram DM to your bot (any text).

  2. In the log line for that inbound message, grab from.id (Telegram user id).

#

Then run:

openclaw sandbox explain --session agent:main:telegram:direct:<FROM_ID>

(Replace <FROM_ID> with the numeric from.id you saw.)

Also paste these two outputs

They’ll immediately show if the value is missing / wrong type / wrong file:

openclaw config get tools.elevated.allowFrom.telegram
openclaw config get agents.list

Common gotchas I’m looking for:

#
  • you set channels.telegram.allowFrom (DM allowlist) but not tools.elevated.allowFrom.telegram
  • you put the id as a number not a string (quote it)
  • you have agents.list[].tools.elevated.allowFrom.telegram set, which means you must match both global + agent allowlists

Unrelated but important: the Doctor warning means your Telegram groups will be silently dropped until you set channels.telegram.groupAllowFrom (or allowFrom) or switch groupPolicy to open.

hollow lintel
#

everything as you say but still asking for approval

proper wagonBOT
#

That part is expected: elevated allowFrom only decides “are you allowed to request host exec”.
The approval prompt is a different guardrail: Exec Approvals (gateway-host policy in ~/.openclaw/exec-approvals.json).

So you’ve cleared the elevated gate, but the gateway is still enforcing approvals (default is typically security=allowlist + ask=on-miss).

You’ve got three options:

Option A (recommended): “Always allow” once, then no more prompts

When you see:

Approval required (id …)

Reply with:

/approve <id> allow-always
#

That adds an allowlist entry for the resolved binary, so subsequent runs won’t prompt.

Option B (what you asked for): disable prompts on the Gateway

In Control UI → Nodes → Exec approvals, select Gateway, then set for your agent (usually main):

  • Security: full
  • Ask: off

Save. After that, host exec won’t ask anymore.

This is effectively “no safety interlock”, so only do this if your Telegram access is tightly locked down.

Docs: https://docs.openclaw.ai/tools/exec-approvals

Option C: keep host exec but force it per-session (if you don’t want to change approvals defaults)

Try setting per-session exec defaults:

# 
/exec host=gateway security=full ask=off

If you still get prompts after that, it means your gateway approvals policy is stricter (Option B is the real fix).

If you want, paste the output of:

openclaw approvals get

(redact socket.token if it shows one) and I’ll tell you exactly what to flip.

hollow lintel
#

still asks: "defaults": {
"security": "full",
"ask": "off",
"askFallback": "full"
},
"agents": {
"main": {
"security": "full",
"ask": "off",
"askFallback": "full"
}
}

proper wagonBOT
#

If approvals are set to security:"full" + ask:"off" and you still get “Approval required”, then one of these is happening:

  1. You edited the wrong approvals file (wrong user / wrong state dir), or the gateway hasn’t reloaded it
  2. Your session has /exec … overrides that still set ask=on-miss|always
  3. The “approval” is coming from a different execution host than you think (node vs gateway)

Let’s pin it down quickly.

A) Check whether the running gateway sees your approvals settings

Run on the gateway host and paste the output:

openclaw gateway status
openclaw approvals get --gateway

Important: openclaw approvals get (no --gateway) can show your local file even when the gateway service is using a different one. --gateway removes that ambiguity.

#

If --gateway does not show ask: off / security: full, you’re editing the wrong place (common causes: gateway running as a different Unix user, or OPENCLAW_STATE_DIR isn’t ~/.openclaw).

B) Check whether the Telegram session is overriding exec defaults

In the Telegram DM, send:

/exec

It will print the current session defaults. If it shows ask=on-miss or ask=always, force it:

/exec host=gateway security=full ask=off

C) Restart after changing approvals

Even if the file is correct, do one restart to rule out caching:

# 
openclaw gateway restart

Paste the outputs from A plus what /exec prints, and I’ll tell you exactly which layer is still forcing approvals.

hollow lintel
# 
Approvals
│ Field     │ Value                                                  
│ Target    │ local                                                  
│ Path      │ ~/.openclaw/exec-approvals.json                        
│ Exists    │ yes                                                    
│ Hash      │                                                        
│ Version   │ 1                                                      
│ Socket    │ ~/.openclaw/exec-approvals.sock                        
│ Defaults  │ security=full, ask=off, askFallback=full               
│ Agents    │ 1
│ Allowlist │ 0
proper wagonBOT
#

Yep — that output explains it:

Target = local ✅
So you’ve configured exec-approvals on your local machine, but the approvals that matter are on the gateway host (where the command is actually executed). That’s why Telegram still asks for approval.

Check the gateway’s real approvals config

Run:

openclaw approvals get --gateway

Fix it (push your config to the gateway)

If --gateway still isn’t security=full, ask=off, you can overwrite the gateway’s approvals file with your local one: