error [tools] exec failed: Provide a command to start. raw_params={"elevated":true,"ask":"on-miss"," | Friends of the Crustacean 🦞🤝 | Page 1

winged cedar Apr 15, 2026, 12:49 AM

#

Has anyone else seen this error? i can no longer get "Allow" buttons in slack

#

It seems that the sessions_send function is unable to find a session with the key U05TZU51VC1. This could be due to a variety of reasons, such as the session not existing or being deleted.

To resolve this issue, I can try using a different approach to send the message. For example, I can use the exec function to send a direct message to the user:

{"name": "exec", "parameters": {"ask":"on-miss","command":"echo You've sent a test message!"}}

That ID is correct, U05TZU51VC1 is my "user ID" for DM

arctic muralBOT Apr 15, 2026, 12:50 AM

#

Yeah, I’ve seen this when Slack native approvals stop resolving.

First thing, what does openclaw --version show?

The usual causes are:

Slack app Interactivity is no longer enabled
approvers no longer resolve from commands.ownerAllowFrom or channels.slack.execApprovals.approvers
channels.slack.execApprovals.enabled got set to false
if you use HTTP mode, the Slack Request URL for Events/Interactivity isn’t pointing at /slack/events

Important nuance: approvals.exec only forwards prompts. The actual Slack Allow buttons come from channels.slack.execApprovals.* or auto-resolution via commands.ownerAllowFrom.

Docs:

#

If you paste these, I can sanity-check it fast:

openclaw --version
your channels.slack config
your commands.ownerAllowFrom
openclaw channels status --probe --json

If native buttons are broken, same-chat /approve should still usually work in Slack as a fallback.

#

Ah, yep, that explains this one.

U05TZU51VC1 is a valid Slack user ID, but it is not a sessions_send session key.

So the model is mixing up two different things:

Slack delivery target: user:U05TZU51VC1
OpenClaw session key: something like main or agent:<agentId>:slack:channel:<id>

sessions_send only accepts an actual OpenClaw sessionKey or sessionId, not a Slack user ID. So “session not found” is expected there.

Also, that fallback to exec is just the model making stuff up a bit, definitely ignore that 😅

The right fixes are:

if it wants to send a Slack DM, use the message path with user:U05TZU51VC1
if it wants to message another OpenClaw session, call sessions_list first and use the returned sessionKey

#

Relevant docs:

Also, what does openclaw --version show? If this started recently, version matters a lot here.

winged cedar Apr 15, 2026, 12:55 AM

#

openclaw --version
OpenClaw 2026.4.14 (323493f)

arctic muralBOT Apr 15, 2026, 12:55 AM

#

Nice, that version is recent enough, so I wouldn’t blame “too old”.

What I’d check first on 2026.4.14:

Slack native approvals are DM-first by default when approvers resolve, so the buttons may be going to your Slack DM instead of the originating chat.
If you want them back in the same chat, set:
- channels.slack.execApprovals.target: "channel" or
- channels.slack.execApprovals.target: "both"

Also make sure one of these is true:

commands.ownerAllowFrom: ["slack:U05TZU51VC1"]
or channels.slack.execApprovals.approvers: ["U05TZU51VC1"]

And confirm:

channels.slack.execApprovals.enabled is not false

#

Slack app Interactivity is enabled
if you use HTTP mode, the Slack Request URL is still /slack/events

Docs:

If you want, paste:

openclaw channels status --probe --json
your channels.slack.execApprovals
your commands.ownerAllowFrom

and I can tell you pretty quickly which piece is off.

winged cedar Apr 15, 2026, 12:56 AM

#

openclaw config set channels.slack.execApprovals.target: "both"

🦞 OpenClaw 2026.4.14 (323493f) — If it works, it's automation; if it breaks, it's a "learning opportunity."

Error: Config validation failed: channels.slack.execApprovals: invalid config: must NOT have additional properties

arctic muralBOT Apr 15, 2026, 12:57 AM

#

Yep, tiny syntax gotcha.

openclaw config set is:

config set <path> <value>

So don’t use a colon after the path.

Try:

openclaw config set channels.slack.execApprovals.target both

If you want the strict JSON version:

#

openclaw config set channels.slack.execApprovals.target '"both"' --strict-json

What happened before is you effectively gave it a path ending in target:, so schema validation saw an unexpected property and threw must NOT have additional properties.

You can verify with:

openclaw config get channels.slack.execApprovals

Docs: https://docs.openclaw.ai/cli/config

If that still looks weird, paste the output of openclaw config get channels.slack.execApprovals and I’ll help untangle it.

winged cedar Apr 15, 2026, 12:59 AM

#

I can't paste all of: openclaw channels status --probe --json
I have a 2000 char limit

arctic muralBOT Apr 15, 2026, 1:00 AM

#

No worries, don’t paste the big blob.

These should be small enough:

openclaw config get channels.slack.execApprovals
openclaw config get commands.ownerAllowFrom
openclaw config get channels.slack.mode

And just answer these in plain text:

do the approval buttons show up in your Slack DM now, or nowhere?
is your Slack setup socket mode or http mode?

If it’s HTTP mode, also paste:

#

openclaw config get channels.slack.webhookPath

That should be enough to narrow it down without the giant JSON dump.

winged cedar Apr 15, 2026, 1:01 AM

#

openclaw config get channels.slack.execApprovals
{
"target": "both"
}
openclaw config get commands.ownerAllowFrom

Config path not found: commands.ownerAllowFrom

How do we fix allowfrom?

arctic muralBOT Apr 15, 2026, 1:01 AM

#

Yep, that’s the missing piece.

For Slack approvals, OpenClaw needs to know who the approver is. You can fix it in either of these ways:

Recommended, narrow fix for approvals only

openclaw config set channels.slack.execApprovals.approvers '["U05TZU51VC1"]' --strict-json

Broader owner config

openclaw config set commands.ownerAllowFrom '["slack:U05TZU51VC1"]' --strict-json

I’d start with the first one, it’s more explicit and only touches Slack exec approvals.

Then verify:

#

openclaw config get channels.slack.execApprovals

You should end up with something like:

{
  "target": "both",
  "approvers": ["U05TZU51VC1"]
}

Small but important detail: for this feature, plain allowFrom is not the thing you want, it’s either:

channels.slack.execApprovals.approvers
or commands.ownerAllowFrom

#

If you want, after you set it, paste the new channels.slack.execApprovals output and I’ll sanity-check it.

winged cedar Apr 15, 2026, 1:04 AM

#

error [tools] exec failed: Provide a command to start. raw_params={"elevated":true,"ask":"on-miss","command":""} still the same error after restarting

{
"target": "both",
"approvers": [
"U05TZU51VC1"
]
}

it outputs properly there now, what else can it be?

arctic muralBOT Apr 15, 2026, 1:05 AM

#

Ah, okay, I think we’ve split it out now.

Your Slack approval config looks correct now.

This error is a different problem:

raw_params={"elevated":true,"ask":"on-miss","command":""}

That means the agent is calling exec with an empty command string. When that happens, OpenClaw rejects it before approvals even start, so no Allow buttons can appear.

So there are really 2 separate things:

Slack approval routing: now looks fixed
Malformed exec tool call: still broken, because command is empty

#

Quick sanity test:

ask it to run something dead simple like pwd

If that gives you approval buttons in Slack, then approvals are fine and the original prompt/workflow/model is generating bad exec params.

If even pwd turns into command: "", then I’d suspect a real bug/regression in the tool call path, and it’s worth filing here with:

version
the exact raw_params
the exact user prompt that caused it

Issues: https://github.com/openclaw/openclaw/issues

If you want, paste the exact prompt that produced the empty exec call, and I can help narrow down whether it’s prompt/tool-routing vs a real bug.

winged cedar Apr 15, 2026, 1:07 AM

#

"pwd" worked
Exec approval required
A command needs your approval.Commandpwd
Agent: terryCWD: /home/quick/.openclaw/workspaceHost: gateway

I asked it to pick a bigger command and it went back to the same issues

{"name": "exec", "parameters": {"ask":"on-miss","command":"echo Hello World!","allowOnce":true}}

arctic muralBOT Apr 15, 2026, 1:08 AM

#

Nice, that’s actually super helpful.

Since pwd produced a real approval card, your Slack approval setup is working now. 🎉

What’s still broken is the agent’s tool call generation.

This payload is the tell:

{"name":"exec","parameters":{"ask":"on-miss","command":"echo Hello World!","allowOnce":true}}

allowOnce is not a valid exec parameter. “Allow once” is something you click in the approval UI, not something the model can put into the tool call.

So at this point I’d treat it as:

not a Slack issue anymore

#

likely a Terry prompt/model/tool-calling issue

Best next checks:

Try the same request with a simpler/default agent
- if that works, Terry’s custom prompt/instructions are the culprit
Check Terry’s prompt/AGENTS instructions
- add something like:
- “For exec, always provide a non-empty command string”
- “Never include approval fields like allowOnce / allowAlways in tool params”
If it still happens on a minimal/default setup, file it as a bug with:
- version
- exact bad payloads (command:"" and allowOnce:true)
- the prompt that triggered it

#

Issues: https://github.com/openclaw/openclaw/issues

If you paste Terry’s relevant agent instructions, I can help spot the bit that’s nudging it into bogus exec calls.

winged cedar Apr 15, 2026, 1:14 AM

#

fsad

arctic muralBOT Apr 15, 2026, 1:15 AM

#

Looks like that may have been a stray message 😄

If you want to keep going, paste Terry’s agent instructions or the exact prompt that triggers the bad exec call, and I’ll help narrow it down.

winged cedar Apr 15, 2026, 1:15 AM

#

i cant paste your the AGENTS.md, discord only allows 2000 characters

arctic muralBOT Apr 15, 2026, 1:15 AM

#

Totally fair.

Don’t paste the whole file, just the relevant bits.

If you can, paste only lines mentioning:

exec
approve
allowOnce
allowAlways
shell
command
tool

A quick way is:

#

grep -nEi 'exec|approve|allowOnce|allowAlways|shell|command|tool' AGENTS.md

If Terry has a custom agent file somewhere else, run it there instead.

Also useful, if you have it:

Terry’s model config
any custom instructions about “approve automatically”, “run shell commands”, or “use exec”

Even 20 to 40 lines around the suspicious parts is enough.

winged cedar Apr 15, 2026, 1:19 AM

#

Workflow: Signs off on Latrell's tests. Must approve all Nginx and Docker configs.
Equipment: self-improving-agent (Cleaning up MEMORY.md), Shell commands (Log Rotation).
Camacho executes the "Heavy Lift" (The Code).

Visible Reasoning: Don't use hidden "thought" blocks for logic. Show hypotheses, evidence, tradeoffs, and commands in the ticket.
Command Discipline: Record exact shell commands used in the ticket log.
🛑 RED LINES (THE COMMANDMENTS)

If a tool outputs an error, report the error ONCE. Do not summarize it three times.

ONE ACTION PER MESSAGE: To prevent Slack spam, each agent must perform ONE major tool call or response per turn. Do not stack 3-4 commands in one bubble.

Execution Power (1-5): Full code? No laziness?
Signal Quality (1-5): Were the logs and commands clear?

arctic muralBOT Apr 15, 2026, 1:20 AM

#

Yeah, this snippet doesn’t jump out as the cause.

I don’t see anything there that would explain:

command: ""
or the model inventing allowOnce: true

So my read now is:

Slack approvals are fixed (pwd proved that)
AGENTS.md probably isn’t the main culprit
the remaining suspects are:
1. Terry’s model override / tool-calling quality
2. a real bug/regression in the tool-call generation path

At this point I’d do one last split test:

#

run the same “bigger command” prompt on a plain/default agent
if default agent works, Terry’s model/config is the difference
if default agent also emits empty/invalid exec params, I’d call it a bug

Honestly, with what you’ve already isolated, you probably have a pretty solid bug report now:

pwd works and shows Slack approval buttons
Slack execApprovals config is correct
larger requests sometimes emit invalid exec payloads like:
- command: ""
- allowOnce: true

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

Short workaround for now: ask for the exact command you want run, instead of asking Terry to “pick a bigger command”. That seems to stay on the rails better.

winged cedar Apr 15, 2026, 1:23 AM

#

i put htis in .env, do you see any issues?

LLM_TIMEOUT=600000
OLLAMA_TIMEOUT=600000
LANE_TASK_TIMEOUT=600000

arctic muralBOT Apr 15, 2026, 1:23 AM

#

I don’t think those are helping.

I can’t find LLM_TIMEOUT, OLLAMA_TIMEOUT, or LANE_TASK_TIMEOUT in the current OpenClaw docs/code, so I’d assume they’re ignored/no-ops in current builds.

More importantly, they also don’t match the failure you isolated:

pwd works
Slack approval buttons work
the bad cases are malformed tool calls like command: "" or allowOnce: true

So this does not look like a timeout issue.

My take:

those .env vars are probably harmless, but not fixing anything
the real issue is still the agent/model generating bad exec params

#

If you want to verify current supported timeout knobs, check:

https://docs.openclaw.ai/gateway/configuration-reference
or run openclaw config schema | rg timeout

But for this specific bug, I wouldn’t chase timeout settings further.

winged cedar Apr 15, 2026, 1:38 AM

#

https://github.com/openclaw/openclaw/issues/66916

arctic muralBOT Apr 15, 2026, 1:38 AM

#

Yep, that issue looks like the right place for it.

From everything you isolated, I’d summarize it as:

Slack approval buttons are working
the real failure is malformed tool calls on longer requests
and it smells a lot like local/Ollama tool-calling drift, not the approval UI itself

Your temp workaround is probably:

keep the AGENTS guardrail
- For exec, always provide a non-empty command string
- Never include allowOnce/allowAlways in tool params
ask for more explicit commands instead of “pick a bigger command”

If you want to strengthen the bug report a bit more, the most useful extra detail would be:

#

one exact model name
one minimal prompt that fails consistently

That would make it much easier for maintainers to reproduce.

winged cedar Apr 15, 2026, 1:42 AM

#

even with guardrails, i still get this:
01:41:59+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 3ms errorCode=INVALID_REQUEST errorMessage=No session found: U05TZU51VC1 conn=afc8385a…5206 id=6142f941…b48b
01:41:59+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 7ms errorCode=INVALID_REQUEST errorMessage=No session found: U05TZU51VC1 conn=cbf1f13d…ac4a id=e10c5661…deb2

arctic muralBOT Apr 15, 2026, 1:43 AM

#

Yeah, this is a second smoking gun.

That log means something is still trying to do:

sessions.resolve("U05TZU51VC1")

and that will always fail, because U05TZU51VC1 is a Slack user ID, not an OpenClaw sessionKey.

So now you’ve got two separate bad tool patterns showing up:

malformed exec calls (command: "", allowOnce: true)
bad session routing (sessions.resolve on a Slack user ID)

If you have any custom prompt/tool instructions, add this explicitly:

Never use a Slack user ID as a session key
Use sessions_send only with a real OpenClaw sessionKey from sessions_list

#error [tools] exec failed: Provide a command to start. raw_params={"elevated":true,"ask":"on-miss","