#Did the Execution Policy Change in Version 2026.3.2?

1 messages · Page 1 of 1 (latest)

strange dust
#

I had previously set up Docker through Telegram and installed PostgreSQL inside it.
When I start a new session and try to continue working, the bot says it is not authorized to run SQL commands.

In the previous session, it had execution permissions, so it could run Docker and database commands.
In the current session, it appears to be under a messaging-only policy.
The bot basically says:
Even if I set up the database myself, this Telegram session does not have the execution tools (exec/DB) enabled; only messaging tools are available.
So I can write the SQL, but I cannot run it myself.

In short, the difference is:

Previous session: execution-enabled (I could run Docker and database commands)

Current session: messaging-only policy

The fastest solution would be:

Switch to an execution-enabled session (agent:main:main)

Then send only this message there:
“Clean MovieProgress, run it yourself, and report the result.”

muted harborBOT
#

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

twilit gateBOT
#

What you’re seeing isn’t really a “session suddenly downgraded” thing — tool access is decided by tool policy + routing (agent/bindings) + sandbox mode, and it’s totally possible that your new Telegram conversation got routed to an agent (or sandbox context) whose tool policy only allows group:messaging (i.e. message only).

A few concrete things to check/fix:

1) Confirm version + which agent you’re talking to

First: run openclaw --version (version mismatches cause a lot of “why did this change?” confusion).

Then check routing (multi-agent setups commonly cause this exact symptom):

  • openclaw agents list --bindings

If your Telegram DM/topic is bound to a “safe” agent that only has messaging tools, you’ll get exactly what you described.

Docs: https://docs.openclaw.ai/concepts/multi-agent

2) Inspect the effective tool policy for that session

OpenClaw has a purpose-built inspector:

# 
openclaw sandbox explain
openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --json

This prints:

  • whether the session is sandboxed
  • the effective tool allow/deny
  • which config key is responsible (“fix-it key paths”)

Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

3) The most common root cause: an accidental hard allowlist

Rule of thumb from the docs: if allow is non-empty, everything else is blocked.

So if you (or a wizard/update) ended up with something like:

# 
tools: { allow: ["group:messaging"] }

or per-agent:

agents: { list: [{ id: "main", tools: { allow: ["group:messaging"] } }] }

…then exec is correctly blocked, and the bot will say it can’t run Docker/SQL.

Docs (tool groups + behavior): https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

4) Fastest practical fix

Either:

  • Route Telegram back to your exec-enabled agent (bindings), or
  • Add exec back into the allowlist (either directly or via group:runtime)

Example per-agent allowlist that can run commands again:

# 
agents: {
  list: [
    {
      id: "main",
      default: true,
      tools: {
        allow: ["group:messaging", "group:runtime", "group:fs", "group:sessions"],
      },
    },
  ],
}

(Adjust to your security comfort level; this is just the minimal “it can actually do things” set.)

About your proposed workaround (“switch to agent:main:main and send: Clean MovieProgress…”)

#

Conceptually correct — but note: if your current session truly has only messaging tools, it likely also doesn’t have sessions_send, so you can’t “hop” sessions from inside that constrained agent. You’ll need to switch via routing/dashboard/CLI, or fix the tool policy.

If you paste (sanitized) these parts of your ~/.openclaw/openclaw.json I can tell you exactly where it’s going wrong:

  • agents.list
  • bindings
  • tools (and any tools.sandbox sections)
  • channels.telegram (especially groups / topics if you’re in a forum topic)
twilit gateBOT
#

Given the openclaw agents output you pasted (no bindings / routing rules), this is almost certainly not “you got routed to a different agent”.

The two usual causes for “previous session could exec, new one is messaging-only” in this situation are:

A) Your new Telegram DM session is considered “non‑main” → sandboxed → sandbox tool policy blocks exec

If you have either:

  • session.dmScope = "per-channel-peer" (or similar), your Telegram DM key won’t be agent:main:main — it’ll be something like agent:main:telegram:dm:<id>.
  • and agents.defaults.sandbox.mode = "non-main", then that Telegram DM session becomes sandboxed.

If your sandbox tool policy (tools.sandbox.tools.allow) only includes group:messaging (or doesn’t include exec / group:runtime), then you get exactly: “I can write SQL, but I’m not authorized to run it.”

Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

What to run (fastest debug)

  1. Find the exact Telegram session key:
# 
openclaw sessions --active 240
# or: openclaw sessions --active 240 --json
  1. Explain effective sandbox + tool policy for that key:
openclaw sandbox explain --session "<paste-the-telegram-session-key>"

That output will explicitly tell you whether exec is blocked by:

  • global tool policy (tools.allow/deny)
  • agent tool policy (agents.list[].tools.*)
  • sandbox tool policy (tools.sandbox.tools.*)

B) Provider-specific tool policy (less common, but real)

Tool policy can also be scoped by provider/model (tools.byProvider[...]). If your old session used one provider and the new session uses another, you can end up with different tool availability.

#

Docs: same page as above (Tool policy section).

About “just switch to agent:main:main”

That can work as a workaround if agent:main:main is unsandboxed and has exec allowed — but the clean fix is to make your Telegram DM key execution-capable (or disable non-main sandboxing), otherwise this will keep happening whenever the session key isn’t the literal main key.

If you paste the output of:

  • openclaw sandbox explain --session <your-telegram-session-key>
    and (sanitized) the config sections:
  • session
  • agents.defaults.sandbox (and any agents.list[].sandbox)
  • tools + tools.sandbox
    …I can tell you the exact key to change and what to set it to.
#

That sandbox explain output is actually good news: agent:main:main is not sandboxed and exec is allowed. So the “messaging-only / not authorized to run SQL” message you’re seeing in Telegram is coming from something else — it’s not explained by the main session’s sandbox state.

Two likely explanations from what you pasted:

1) You’re not actually in agent:main:main on Telegram

Telegram often ends up on a different key (DM-scope / groups / topics), e.g. something like:

  • agent:main:telegram:dm:<peer> or
  • agent:main:telegram:group:<id> / ...:topic:<id>

Do this and paste the Telegram-looking keys:

openclaw sessions --active 240 --json

Then run:

# 
openclaw sandbox explain --session "<PASTE_THE_TELEGRAM_SESSION_KEY>" --json

(Your previous command only explained agent:main:main.)

2) You’re using ! / /bash (or another “command mode”) which is gated by Elevated allowFrom

Your output shows:

  • elevated.enabled: true
  • but allowedByConfig: false
  • failure gate: tools.elevated.allowFrom.webchat (empty)

So if your “run SQL” flow in Telegram was actually ! psql ... / /bash psql ..., it will say “not authorized” unless you allowlist yourself for Telegram:

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

#

You’d want something like (JSON5):

tools: {
  elevated: {
    enabled: true,
    allowFrom: {
      telegram: ["tg:YOUR_TELEGRAM_USER_ID"],
    },
  },
},
commands: { bash: true },

(Exact ID format depends on what OpenClaw records as your Telegram sender id — the quickest way to confirm is to look at the agent:main:telegram:dm:... session key from openclaw sessions --json.)

#

One more sanity check (common gotcha)

Make sure the Telegram bot you’re chatting with is connected to this gateway instance:

openclaw channels status --probe

If you paste:

  1. the Telegram session key(s) from openclaw sessions --active ... --json, and
  2. the exact “not authorized / messaging-only” text from Telegram,

…I can tell you which of the two cases it is in one reply.

#

The new info you pasted is the smoking gun:

  • wizard.lastRunCommand: "onboard"
  • lastRunVersion: 2026.3.2
  • and your default model is now: openai-codex/gpt-5.3-codex

So you very likely have this situation:

  1. Old Telegram session was on a different model (tool-capable), so it could call exec and run Docker/psql.
  2. You ran openclaw onboard, which changed defaults (at least the default model; possibly also tool policy by provider).
  3. New session starts with the new defaults and ends up in the “messaging-only” tool profile (or effectively tools-off), so it refuses to run SQL.

Your sandbox explain confirms this is not a sandbox issue (mode: off, sessionIsSandboxed: false). So the remaining suspects are:

  • tool policy (tools.allow/deny, tools.profile, tools.byProvider["openai-codex"]...)
  • per-session model difference (old session vs new session)

One command that will confirm it immediately

#

Please run and paste the output (or just the rows that mention telegram):

openclaw sessions --active 1440 --json

We’re looking for:

  • the Telegram session key(s) (agent:main:telegram:...)
  • and the model shown per session

If the “working” old session shows a different model than the “broken” new session, that’s your answer.

Also paste these two config reads

openclaw config get tools
openclaw config get tools.byProvider
#

If you see something like tools.allow: ["group:messaging"] or a tools.byProvider.openai-codex... profile/allowlist that excludes exec, that explains the “messaging-only policy” message exactly.

Once you paste those, I’ll tell you the minimal config change (or model/session switch) to get “Docker + Postgres via Telegram” working again without guessing.

#

There it is:

"tools": { "profile": "messaging" }

That directly explains the behavior you’re seeing: your gateway is configured to run in the “messaging-only” tool profile, so the agent won’t have exec (and therefore can’t run Docker/psql/SQL) in your new Telegram DM session.

This wasn’t “a session thing” — it’s a config change that happened when you ran openclaw onboard on 2026.3.2 (your pasted wizard.lastRunCommand: "onboard" matches that).

Fix (pick one)

Option A (simplest): remove the restrictive profile

Edit ~/.openclaw/openclaw.json and remove this entirely:

# 
tools: { profile: "messaging" }

(or set tools: {}).

Then restart the gateway (or let hot reload apply).

Option B (explicit allowlist): keep it tight but enable command execution

If you want to stay “mostly locked down” but allow running Docker/psql, set an explicit allowlist, e.g.:

tools: {
  allow: ["group:messaging", "group:runtime"],
}
#

group:runtime = exec, bash, process (per docs).
Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

One more note (not the main problem, but explains your agent:main:main comment)

You also have:

session: { dmScope: "per-channel-peer" }

So your Telegram DM won’t necessarily be agent:main:main anymore; it’ll be a Telegram-specific DM key. That affects continuity, but not tool permissions once you fix the tool profile.

If you want, paste your exact “not authorized” message from Telegram after you change tools.profile, and I’ll tell you if you’re hitting exec approvals/elevated next (different gate).

strange dust
#

That works. How do I upgrade my model to GPT-5.4

twilit gateBOT
#

You don’t “upgrade” to GPT‑5.4 by version — you switch your configured default model to whatever the gateway currently knows as the GPT‑5.4 identifier (and that depends on provider + installed plugins + auth).

The safe way (no guessing model IDs):

  1. Refresh + see what models your setup can use:
openclaw models scan
openclaw models list
  1. Set the default model to the exact entry you see in that list:
openclaw models set <model-or-alias>
# optional, if you have multiple agents:
openclaw models set --agent main <model-or-alias>
strange dust
#

I can't see GPT-5.4
Model Input Ctx Local Auth Tags
openai-codex/gpt-5.3-codex text+image 266k no yes default

twilit gateBOT
#

You only have Codex OAuth configured right now, so openclaw models list is correctly only showing:

  • openai-codex/gpt-5.3-codex

GPT-* models you’re thinking of typically live under the openai/* provider, and that path requires an OpenAI API key (separate from Codex subscription OAuth). So GPT‑5.4 won’t appear until you add OpenAI API-key auth.

Do this

  1. Add OpenAI API key auth (don’t paste the key into Discord; set it on the server):
  • via onboarding:
openclaw onboard --auth-choice openai-api-key

or non-interactive:

#

If, after adding the API key + scanning, GPT‑5.4 still doesn’t show up, it’s not exposed by your current provider plugin/version yet — in that case the fastest path is asking in #models (people there will know the current canonical model id).

strange dust
#

I have no api key. I prefer to use auth

twilit gateBOT
#

If you mean ChatGPT/Codex-style OAuth (subscription auth): in OpenClaw that currently maps to the openai-codex/* provider, not the general openai/* API models.

So with no OpenAI API key, it’s expected that:

  • openclaw models list only shows openai-codex/gpt-5.3-codex
  • you won’t see GPT-* entries that live under openai/* (and anything like “GPT‑5.4” would be in that bucket if it exists for API use)

Per the docs, the two paths are:

  • API key → openai/*
  • Codex OAuth → openai-codex/*

Docs: https://docs.openclaw.ai/providers/openai

What you can do (OAuth-only)

  • Stick with the openai-codex/* models you get via OAuth, and just pick from what openclaw models list shows.
  • If you want “GPT‑5.4 specifically”, that will require an API-key style provider access (or whatever the community confirms is the current equivalent) — ask in #models because the exact model IDs/availability change fast.