Error after setup

[radiant sage]

That screenshot only shows the TUI footer state: local runtime is ready, but the main agent run errored while using openrouter/minimax/minimax-m2.7. The actual cause should be in status/logs, not the footer.

Can you paste these outputs? Please redact any tokens/API keys if they appear:

openclaw --version
openclaw status --all
openclaw models status --probe
openclaw logs --limit 120 --plain

Most likely buckets are: missing/invalid OpenRouter auth, model not allowed/available, or that model failing the request shape. The docs’ first debug loop is here: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken and model diagnostics are here: https://docs.openclaw.ai/concepts/models#models-status.

[radiant sage]

That one is still the generic TUI wrapper error. It means the agent turn failed, but it doesn't include the real exception.

Please run these on the same machine and paste the text output:

openclaw --version
openclaw models status --probe
openclaw logs --limit 120 --plain

Since your footer showed openrouter/minimax/minimax-m2.7, the fastest thing to check is whether OpenRouter auth is valid and that model is actually usable. If models status --probe says OpenRouter auth is missing, run:

openclaw models auth paste-token --provider openrouter
openclaw models status --probe

[radiant sage]

Docs for the exact debug flow: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken
Model auth/probe docs: https://docs.openclaw.ai/gateway/authentication#model-provider-auth

[jagged scroll]

this is a new issue i get while trying to use it in telegram after running these commands and restarting the gateway

openclaw config set tools.profile full
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw config set tools.exec.host gateway

[radiant sage]

Those commands only open the OpenClaw-side exec policy. For no-approval gateway exec, there’s a second host-local approvals layer too. If that layer doesn’t match, Telegram runs can still fail or stall around exec approvals.

First, please paste the actual Telegram error/log line if you can:

openclaw --version
openclaw logs --limit 160 --plain
openclaw config get tools

If your goal is “let my Telegram agent run gateway shell commands without approval prompts”, use the supported local shortcut on the gateway machine:

openclaw exec-policy preset yolo
openclaw gateway restart

[radiant sage]

or set the host approvals file explicitly:

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
openclaw gateway restart

Important: tools.profile full + tools.exec.security full + ask off is very permissive. I’d only use that for a private Telegram DM/account you control, not a group or anything exposed to other users.

[radiant sage]

Docs: https://docs.openclaw.ai/tools/exec-approvals#no-approval-yolo-mode

[jagged scroll]

I keep getting this after asking my agent to create other agents for me could it be the model im using?

It just stalls

[radiant sage]

This screenshot is useful: the exec tool is actually running and completing openclaw status, then the turn fails afterward. So this no longer looks like the exec approval layer itself; it’s more likely one of:

• the selected model/provider choking after tool output
• Telegram reply/streaming formatting failing
• an exception in the gateway after the tool result is returned

Please paste text logs, not another screenshot:

openclaw --version
openclaw logs --limit 200 --plain
openclaw models status --probe

For a quick isolation test, try the same prompt in local TUI after a fresh session:

[radiant sage]

openclaw tui
/new
run openclaw status

If TUI works but Telegram fails, we look at Telegram delivery/streaming. If both fail after tool output, it’s probably model/provider/runtime. Since your earlier footer showed OpenRouter + MiniMax, I’d also test a different tool-reliable model; for current model picks, #models has fresher hands-on advice than I do.

Docs for the debug ladder: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken
Exec approvals docs, for reference: https://docs.openclaw.ai/tools/exec-approvals#no-approval-yolo-mode

[radiant sage]

If it stalls right after the tool card says completed, I’d isolate the two likely pieces:

1. Disable Telegram streaming/preview edits temporarily:

openclaw config set channels.telegram.streaming off
openclaw gateway restart

Then retry the same Telegram prompt. If that fixes it, the issue is in Telegram preview/edit delivery, not exec.

2. If it still stalls, switch away from the OpenRouter MiniMax session/model and try the same prompt with another configured model. The earlier screenshots showed openrouter/minimax/minimax-m2.7, and stalls after tool output are often provider/tool-output handling rather than the shell command itself.

Please still paste this when you can, because it should name the exact failure:

[radiant sage]

openclaw --version
openclaw logs --limit 200 --plain
openclaw models status --probe

Telegram streaming docs: https://docs.openclaw.ai/channels/telegram#live-stream-preview-message-edits

[jagged scroll]

so i did a fresh install of openclaw and added openclaw exec-policy preset yolo and since then it has broke and errors

[radiant sage]

First thing: what does openclaw --version show, and what’s the exact error text?

Since this started after openclaw exec-policy preset yolo, also paste:

openclaw exec-policy show
openclaw approvals get
openclaw status --all

That preset is local-only and updates both local tools.exec.* config and ~/.openclaw/exec-approvals.json. If the issue is specifically exec approvals/policy, you can usually back it out with the conservative preset:

openclaw exec-policy preset cautious
openclaw gateway restart

[radiant sage]

Docs for the relevant bit: https://docs.openclaw.ai/tools/exec-approvals and https://docs.openclaw.ai/cli/approvals

[jagged scroll]

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session. is what I get when asking my agent to create 4 more agents

[radiant sage]

That message is the generic “agent run crashed/failed” wrapper, so the real cause will be in the gateway logs.

Please share:

openclaw --version
openclaw status --all
openclaw logs --follow

Then reproduce the “create 4 more agents” request and paste the log lines that appear right when it fails. Don’t paste tokens/secrets, but status --all is designed to redact them.

A couple useful checks while you’re there:

/subagents list

[radiant sage]

And try spawning just one:

/subagents spawn main say hello

If one works but four fails, it’s probably concurrency/tool-call/model pressure. If one fails too, it’s likely config/auth/session state. Sub-agents are documented here: https://docs.openclaw.ai/tools/subagents

If this started right after the YOLO exec-policy change, I’d also temporarily undo that variable:

openclaw exec-policy preset cautious
openclaw gateway restart

Then retry. If it still fails, the logs are the thing we need next.

[radiant sage]

This status has a pretty strong clue:

Agents │ 1 total · 1 bootstrapping · 1 active
and
main │ Bootstrap file │ PRESENT

That means your main agent is still in first-run/bootstrap mode. Subagents can get weird from there because the parent session may be trying to handle setup instructions instead of normal tool orchestration.

Try moving the bootstrap file aside, restarting, then starting a fresh session:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done
openclaw gateway restart
openclaw status --all

After that, check that it no longer says bootstrapping / Bootstrap file PRESENT, then run /new and try the one-agent test first:

[radiant sage]

/subagents spawn main say hello

If that works, try your 4-agent request again. If it still fails, we’ll need the openclaw logs --follow lines from the moment it crashes.

Relevant docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/tools/subagents

[jagged scroll]

So everything here worked Hey! 👋 Hello to you too — the subagent was just checking in. Everything's up and running, ready to help whenever you need. Have a great day!

but when trying the request again we get the same error

[radiant sage]

Good, that narrows it down: subagents themselves work. The failure is likely in the parent agent’s multi-spawn turn, not basic subagent setup.

Can you try this exact isolation test?

/subagents spawn main worker 1: reply with "one"
/subagents spawn main worker 2: reply with "two"
/subagents spawn main worker 3: reply with "three"
/subagents spawn main worker 4: reply with "four"

If those four manual spawns work, then the problem is probably the parent model/tool orchestration when it tries to create 4 agents in one request. In that case we need:

openclaw logs --follow

[radiant sage]

Then reproduce the failing request and paste the new log lines from that moment.

Also paste the exact prompt you’re giving the agent. The wording matters here: “create 4 more agents” might make it try persistent/session-style agents instead of four one-shot subagents. A safer prompt is:

Spawn 4 one-shot subagents with sessions_spawn, isolated context, mode run. Give each a separate small task, then summarize their results.

Default limits should allow 4 children, so if logs show a limit/auth/tool error, that’s the useful bit.

Yep, the log pins it:

openrouter/minimax/minimax-m2.7 is returning repeated HTTP 500: Internal Server Error, classified as timeout, and OpenClaw says fallbackConfigured=false / chain_exhausted.

So the subagent machinery is working; the main model/provider is failing under that heavier orchestration request.

Next steps:

openclaw models status
openclaw models fallbacks list

Then either switch the current session to a different configured model:

/model

or add a fallback model you already have auth for:

openclaw models fallbacks add <provider/model>
openclaw gateway restart

I’m intentionally not naming a “best” model here because model availability changes fast. For current recommendations, check #models, and the docs are here: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

For now, the practical fix is: don’t use that OpenRouter MiniMax model as the only model for multi-agent orchestration. Use a stronger/more reliable primary, or configure at least one fallback.

[jagged scroll]

Thanks its all fixed

[radiant sage]

Glad that fixed it 🎉

If this solved the thread, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index the fix for future users.