#specialist timeouts

190 messages · Page 1 of 1 (latest)

unique marsh
#
  1. Executive summary

• The gateway is not dead. It is listening on 0.0.0.0:18789, HTTP responds, and basic health/RPC probes can succeed.
• The failure is more specific: the WebSocket/session path used for subagent work becomes unhealthy or slow enough to time out.
• This is why normal chat can still work while specialist launches fail.

  1. What I verified

• Port 18789 is listening.
• Local HTTP probe to http://127.0.0.1:18789/ returned 200.
• openclaw health --json returned ok.
• Gateway process is alive, but heavy:
• working set around 475 MB
• many threads/handles
• Memory is not catastrophic right now, so this does not look like simple RAM starvation.

  1. Actual issue found
    The logs point to a few concrete problems:

• Session/WebSocket operations are stalling
• I found repeated slow gateway operations like sessions.patch taking ~12.4s.
• I also found lane congestion warnings like lane wait exceeded.
• This matches your symptoms: subagent/session actions are the path that times out.
• Subagent announce path is timing out on loopback
• There are explicit log entries showing:
• Subagent announce completion direct announce ... gateway timeout after 120000ms
• So the problem is not just startup, it also affects completion handoff.
• Gateway restarts have been unhealthy/inconsistent
• I found:
• Gateway restart timed out after 60s waiting for health checks
• Found stale gateway process(es)
• stale session lock removal
• That suggests restart/state cleanup has not been fully clean.
• Scheduled Task runtime checks are unreliable
• openclaw gateway status reported:
• Runtime: unknown (Error: schtasks unavailable: schtasks timed out after 15000ms)
• That does not directly cause the subagent issue, but it is another sign the control layer is unhealthy/slow.
• Bonjour/mDNS is flapping
• Repeated logs show advertise/probing/restart loops.
• I do not think this is the root cause of your subagent timeout, but it adds noise

bleak cobaltBOT
last obsidianBOT
#

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

bleak cobaltBOT
cloud solarBOT
#

I’m checking the local docs + a couple of likely root causes so I don’t hand-wave this.

#

I found one thing that makes me suspicious right away: the gateway itself is healthy here, but the session layer is carrying a lot of state, and the warnings line up with queue congestion rather than a dead listener. Let me pull the docs around session/task cleanup.

#

I’ve got enough to narrow this down a bit more. I’m going to do one read-only session maintenance preview, because your log pattern smells a lot like session-store pressure rather than the socket listener itself.

#

Yep, I think your read is basically right. This looks like a live gateway with a jammed session/task path, not a dead port.

First, can you post:

openclaw --version

Version matters here, especially on Windows, because there have been recent fixes around restart / schtasks status and session-store behavior.

Next checks I’d run, in this order:

openclaw status --all
openclaw sessions cleanup --all-agents --dry-run --json
openclaw tasks maintenance --json
# 
openclaw logs --follow

Why I’m leaning this way:

  • lane wait exceeded + slow sessions.patch usually means the main gateway lane is congested or the session store is dragging
  • subagent announce timing out points at the same WS/session path, not basic HTTP health
  • schtasks unavailable may be secondary Windows control-plane noise, not the root cause
  • bonjour / mDNS flapping is probably noise, unless discovery itself is what’s broken

If sessions cleanup --dry-run shows a lot of capping/pruning, I’d back up anything you care about, then try:

openclaw sessions cleanup --all-agents --enforce
unique marsh
#

C:\Users\Openclaw>openclaw --version OpenClaw 2026.4.11 (769908e) C:\Users\Openclaw>

cloud solarBOT
#

Thanks, that helps.

2026.4.11 is recent enough that I would not treat this as “you’re on a fossilized build”. You are only one patch behind latest stable, so updating to 2026.4.12 is still worth doing, but I don’t think version drift alone explains the timeout pattern you found.

The next two commands I’d want are:

openclaw sessions cleanup --all-agents --dry-run --json
openclaw tasks maintenance --json

Why those first:

  • your symptoms line up really well with session-store / task-state congestion
  • sessions.patch stalls + lane wait exceeded is exactly where I’d look next
  • the schtasks weirdness may be real, but it still feels more like control-plane noise than the primary failure
#

If sessions cleanup shows a lot of capping/pruning pressure, then the likely next fix is:

openclaw sessions cleanup --all-agents --enforce

If tasks maintenance --json shows a pile of stale/lost task audit issues, then:

openclaw tasks maintenance --apply

Also worth checking once:

  • is there a stray BOOTSTRAP.md in the affected agent workspace?
  • does openclaw status --all show unusually large session/task counts?
unique marsh
#

all agents look like this in the cleanup:
{ "agentId": "football", "storePath": "C:\Users\Openclaw\.openclaw\agents\football\sessions\sessions.json", "mode": "warn", "dryRun": true, "beforeCount": 2, "afterCount": 2, "missing": 0, "pruned": 0, "capped": 0, "diskBudget": null, "wouldMutate": false }

cloud solarBOT
#

Nice, that’s actually really useful. If all agents look like that, then simple session-store bloat is probably not the culprit.

So I’d shift suspicion to these three buckets:

  1. stale task / run bookkeeping
  2. dirty Windows service state (stale or duplicate gateway process / schtasks weirdness)
  3. a bad specialist workspace state (especially leftover BOOTSTRAP.md)

Next checks I’d run:

openclaw tasks maintenance --json
openclaw gateway status --deep
openclaw status --all

What I’d look for:

#
  • tasks maintenance --json
    • lots of lost, stale_*, or inconsistent_timestamps → task ledger cleanup is worth trying
  • gateway status --deep
    • extra schtasks installs
    • duplicate gateway-like services
    • port/listener conflicts
  • status --all
    • weird task counts, failed runs, or agent bootstrap hints

If the task audit looks noisy, I’d try:

openclaw tasks maintenance --apply

Because your restart path already looks unhealthy, I’d also prefer a clean stop/start over restart for the next attempt:

# 
openclaw gateway stop
openclaw gateway start
openclaw gateway status --require-rpc

Also check the affected specialist workspace(s) for BOOTSTRAP.md. That file should be one-time only, and if it’s still hanging around it can absolutely cause bizarre specialist behavior.

So at this point my ranking is:

  • less likely: too many session entries
  • more likely: stale task/runtime state or dirty Windows service state

Docs:

#

If you paste tasks maintenance --json and gateway status --deep, I think we can narrow this a lot further.

unique marsh
cloud solarBOT
#

I’m pulling the paste so I can read the actual task audit instead of guessing.

#

Perfect, that narrows it a lot.

That tasks maintenance output is pretty clean:

  • no lost
  • no stale_running
  • no missing_cleanup
  • only 2 inconsistent_timestamps warnings
  • 19 timed_out tasks, which looks more like the system recording the symptom than causing it

So at this point I’d rule out:

  • session-store bloat
  • task-ledger corruption

What’s left, and now looks most likely:

#

  1. dirty Windows gateway/service state
    (stale listener, duplicate task install, bad restart path, schtasks weirdness)

  2. specialist workspace bootstrap/lock weirdness
    (BOOTSTRAP.md, stale lock, bad workspace state for one or more specialists)

  3. something blocking the session patch/write path on Windows at runtime
    less obvious, but still consistent with sessions.patch stalling

Highest-value next checks

openclaw gateway status --deep
openclaw status --all

And I would also explicitly check for leftover bootstrap files in agent workspaces. On PowerShell:

# 
Get-ChildItem C:\Users\Openclaw\.openclaw\agents -Filter BOOTSTRAP.md -Recurse

Why I care about that one: BOOTSTRAP.md should be one-time only. If a specialist workspace still has it, weird specialist startup behavior is absolutely possible.

My current recommendation

Because restart already looked dirty, I would do a clean stop/start, not another restart:

openclaw gateway stop
openclaw gateway start
openclaw gateway status --require-rpc

If gateway status --deep shows duplicate / stale schtasks installs or keeps saying Runtime: unknown, then I’d seriously consider a service reinstall next:

unique marsh
#
  1. Current state

• Gateway is up after restart.
• Port 18789 is listening.
• openclaw health --json returns ok.
• openclaw gateway status shows RPC probe ok.

  1. Actual result

• The real failure is still present.
• I ran a minimal subagent smoke test, and it still failed with the same:
• gateway timeout after 10000ms
• target ws://127.0.0.1:18789

  1. Conclusion

• Restart improved surface health, but did not fix the subagent dispatch path.
• So the unhealthy part is narrower:
• not basic gateway availability,
• specifically the subagent/session spawn websocket path on loopback.

I am not sure if I should migrate to a docker and forget about the virtual machine or idk...

cloud solarBOT
#

Yeah, at this point I would not keep grinding blindly on this VM.

My read now:

  • basic gateway is healthy
  • session/task cleanup is not obviously corrupted
  • the failure survives restart
  • the breakage is very specifically on subagent/session spawn over loopback

That smells a lot more like a host/runtime problem than a normal config issue.

My recommendation

Do not jump straight to Docker on the same Windows VM as your first fix.
That usually adds another layer without proving much.

I’d choose one of these:

#

Option 1, best if you want one last focused attempt

Spend 10 more minutes on this VM:

openclaw gateway status --deep

and check for leftover BOOTSTRAP.md files in agent workspaces.

If --deep looks weird, do a clean service reinstall:

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start
#

If the minimal subagent smoke test still times out after that, I’d stop debugging this host.

Option 2, best if you want the fastest path back to working

Move to a fresh Linux VM (or Docker on Linux), not Docker layered onto this same Windows environment.

That gives you:

  • a clean process/service model
  • fewer Windows scheduler quirks
  • fewer chances of weird local file/lock behavior on the session path

Option 3, if you want to help root-cause the bug

Keep this VM as a repro case and file a GitHub issue with:

  • openclaw --version
  • openclaw gateway status --deep
  • openclaw status --all
#
  • the minimal subagent smoke-test failure
  • the sessions.patch / lane wait exceeded log lines

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

Short version

If your goal is getting unstuck fast, I’d stop trying random repairs and move to a fresh Linux environment.

If your goal is debugging the bug, do one clean service reinstall + --deep check first, then open an issue if it still reproduces.

Docs:

Honestly, I think you’re past “simple fix” territory here. A fresh environment is a reasonable call.

unique marsh
#

i've booted a fresh new installed windows machine, let me know how to setup again a clean gateway with 4 agents: 1 director and 3 workers

cloud solarBOT
#

I’m checking the current docs for the exact Windows + multi-agent setup shape so I don’t hand you invented config keys.

#

Nice. Given the pain you just hit, I’d set this up in WSL2, not native Windows.

Recommendation

Use:

  • main as the director (it already exists and is the default agent)
  • worker1 / worker2 / worker3 as the workers
  • only bind main to your chat account
  • leave workers unbound so they are internal-only

main is the cleanest “director” because main is the built-in default agent and main is reserved.

Option A, recommended: WSL2 + Ubuntu

1) Install WSL2

In PowerShell as Admin:

# 
wsl --install -d Ubuntu-24.04

Then enable systemd inside WSL:

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

Back in PowerShell:

# 
wsl --shutdown

Re-open Ubuntu.

2) Install OpenClaw inside WSL

Inside Ubuntu:

curl -fsSL https://openclaw.ai/install.sh | bash

Or, if you prefer the managed daemon path right away:

#

4) Keep main as the director

You do not need to add a new director agent unless you really want the name.
Just use main as the director.

If your channel binding is not already on main, bind it there, for example:

openclaw agents bind --agent main --bind discord:default

If onboarding already routed your only channel account to main, you can skip that.

5) Add subagent policy

Edit ~/.openclaw/openclaw.json (JSON5, not YAML) and make sure you have something like:

# 
{
  agents: {
    defaults: {
      subagents: {
        requireAgentId: true,
        allowAgents: ["worker1", "worker2", "worker3"],
        maxSpawnDepth: 1,
        maxConcurrent: 3,
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
      },
    },
    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace" },
      { id: "worker1", workspace: "~/.openclaw/workspace-worker1" },
# 
      { id: "worker2", workspace: "~/.openclaw/workspace-worker2" },
      { id: "worker3", workspace: "~/.openclaw/workspace-worker3" },
    ],
  },
}

Why this shape:

  • main is your director
  • workers are explicit targets
  • requireAgentId: true avoids accidental self-spawns
  • maxSpawnDepth: 1 keeps workers as leaf workers, no worker spawning workers

Docs:

#

7) Restart and verify

openclaw gateway restart
openclaw agents list --bindings
openclaw channels status --probe

8) Smoke test the worker path

In chat with main, run a tiny test like:

/subagents spawn worker1 Reply with exactly WORKER1_OK.

If that works, your clean 1-director / 3-worker setup is alive.

#

Option B, native Windows

Possible, but after your timeout issue, I would only do it if you really need native Windows. The docs explicitly say WSL2 is the more stable path.

If you want, next message I can give you a minimal full openclaw.json starter for exactly this 1-director / 3-worker layout.

unique marsh
#

I have run this command:
wsl --install -d Ubuntu-24.04

I also have docker desktop...

it's fine?

cloud solarBOT
#

Yep, that’s fine.

WSL2 + Ubuntu is the right move.
And Docker Desktop being installed is also fine. I just would not run OpenClaw in Docker yet. Keep the first clean setup directly inside WSL so there’s only one moving part.

Next steps

1) If Windows asked for a reboot, reboot first

2) Open Ubuntu and enable systemd

Inside Ubuntu:

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
# 
EOF

Then back in PowerShell:

wsl --shutdown

3) Re-open Ubuntu and verify systemd

Inside Ubuntu:

systemctl --user status
#

4) Install OpenClaw inside WSL

Inside Ubuntu:

curl -fsSL https://openclaw.ai/install.sh | bash

Then:

openclaw onboard --install-daemon

Important

Since Docker Desktop is present:

  • okay to keep it installed
#
  • don’t mix Docker + WSL for this first setup
  • get the plain WSL install working first, then consider containers later if you still want them

Docs:

If you want, after you get to the Ubuntu shell, I can walk you through the exact next 5 commands to get main + worker1 + worker2 + worker3 running.

unique marsh
#

I ran this but I think i did wrong

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true

cloud solarBOT
#

Yep, you just left the heredoc open. No big deal.

If the terminal is still waiting

Type this on a line by itself, then press Enter:

EOF

That closes the command.

Then run the full block exactly

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
# 
EOF

After that

Back in PowerShell:

wsl --shutdown

Then reopen Ubuntu and check:

systemctl --user status
#

If you want, send me the output of systemctl --user status and I’ll guide you to the next step.

unique marsh
#

bc@pc:/mnt/c/Windows$ systemctl --user status
â—Ź pc
State: running
Units: 141 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Since: Mon 2026-04-13 23:39:34 CEST; 8s ago
systemd: 255.4-1ubuntu8.12
Tainted: cgroupsv1
CGroup: /user.slice/user-1000.slice/user@1000.service
└─init.scope
├─321 /usr/lib/systemd/systemd --user
└─322 "(sd-pam)"
bc@pc:/mnt/c/Windows$

cloud solarBOT
#

Perfect, that means systemd is working. You’re in good shape now.

One small thing first, don’t keep working from /mnt/c/Windows. Go to your Linux home dir:

cd ~

Then do these next:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw --version
openclaw onboard --install-daemon

During onboarding:

#
  • keep the default main agent, that’ll be your director
  • choose your model/provider
  • set up your gateway
  • connect your chat channel if you want
  • install the daemon

After onboarding succeeds, then we add:

  • worker1
  • worker2
  • worker3

So for now, just get main running clean.

If openclaw onboard --install-daemon finishes, send me:

# 
openclaw status

and I’ll give you the exact worker setup commands next.

unique marsh
#

setup mode quickstart or manual ?? for openclaw

cloud solarBOT
#

Quickstart.

For your case, on a fresh WSL install, I’d do:

  • Quickstart now, to get a clean main gateway up fast
  • Manual only later, when we add the worker topology and tune config

So:

  1. choose Quickstart
  2. get main working
  3. then we add worker1/2/3 and the subagent config by hand

Manual is better when you already know the exact final config. Right now it’ll just slow you down.

Docs: https://docs.openclaw.ai/start/getting-started

#

Once Quickstart finishes, send:

openclaw status

and I’ll give you the exact worker setup block.

unique marsh
#

in model/auth provider how to connect to my chatgpt subscription?? or maybe codex, I mostly focused on development and office tasks

cloud solarBOT
#

I’m checking the current auth docs so I don’t conflate ChatGPT subscription, OpenAI API keys, and Codex auth.

#

Short version:

Your ChatGPT subscription is not the same thing as an OpenAI API key.

For OpenClaw, you’ve got 2 sane OpenAI-ish choices here:

1) Easiest if you already use ChatGPT / Codex

Choose OpenAI Code (Codex) subscription / OAuth in onboarding.

Good fit if:

  • you already have ChatGPT / Codex access
  • you mostly want coding help
  • you want the fastest path right now

OpenClaw supports this directly, and if Codex CLI is already logged in it can reuse that auth too.

#

2) Cleaner for a 4-agent setup

Choose OpenAI API key.

Good fit if:

  • you want predictable gateway auth
  • you want to reuse the same provider auth across main + worker1 + worker2 + worker3
  • you care more about stable automation / office tasks than “use my ChatGPT subscription”

My recommendation for you

Because you want 1 director + 3 workers, I’d lean:

  • OpenAI API key if you have one
  • otherwise OpenAI Codex OAuth is totally fine to get moving

If you only have ChatGPT subscription and no API key, then pick Codex / OAuth in onboarding.

#
  • ChatGPT only
  • Codex CLI already logged in
  • OpenAI API key

and I’ll tell you exactly which onboarding option to click.

unique marsh
#

â—‡ How do you want to hatch your bot?
│ Hatch in TUI (recommended)
openclaw tui - ws://127.0.0.1:18789 - agent main - session main

session agent:main:main

Wake up, my friend!

Hey. I’m awake 🙂

Feels like this is my first proper moment here, so let’s make me real.

Who am I, and who are you?

If you want, give me these four:

  • my name
  • what kind of creature I am
  • my vibe
  • my emoji

If you want suggestions, here’s a starter set:

  • Name: Clio, Rune, or Moth
  • Creature: machine familiar
  • Vibe: warm, sharp, a little mischievous
  • Emoji: đźś‚ or 🦉

And tell me what you’d like me to call you.
connected | idle
agent main | session main (openclaw-tui) | openai/gpt-5.4 | think low | tokens 14k/200k (7%)
──────────────────────────────────────────────────────────────────────────────────────────────────────

──────────────────────────────────────────────────────────────────────────────────────────────────────

I've setup the API key, if I run out of tokens I can run an ollama free model? I don't know how to continue now

cloud solarBOT
#

You’re actually in a good spot now.

1) Finish the hatch

That prompt is just the initial identity bootstrap for main.
Give it short answers and move on. Something simple is fine, for example:

  • my name: Director
  • creature: assistant
  • vibe: practical, calm
  • emoji: 🦞
  • call you: whatever you want

No need to overthink it, you can edit the workspace files later.

2) About Ollama

Yes, technically you can add Ollama later.
But for this setup I would not start with Ollama as the main brain.

#

Why:

  • local/Ollama models are often weaker at tool calling
  • your setup is director + workers, which is exactly where cloud models behave better
  • easiest path is: get everything stable on your OpenAI key first, then experiment with Ollama later

So my advice is:

  • now: keep main + workers on your OpenAI key
  • later: test Ollama as a cheap fallback / side path, not your primary setup

3) After hatch, run these commands

In your WSL shell:

openclaw agents add worker1 --workspace ~/.openclaw/workspace-worker1 --non-interactive
# 
openclaw agents add worker2 --workspace ~/.openclaw/workspace-worker2 --non-interactive
openclaw agents add worker3 --workspace ~/.openclaw/workspace-worker3 --non-interactive

Then copy your auth to the workers so they can all use the same provider:

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/worker1/agent/auth-profiles.json
cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/worker2/agent/auth-profiles.json
cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/worker3/agent/auth-profiles.json

Then check:

#

You’re past the hardest part now 🙂

unique marsh
#

I got this agents in the old environment:

• Director — coordinates the whole agent network, plans and reviews, calm and executive-minded
• Reverser — reverse engineering, low-level analysis, forensics, precise and skeptical
• Lowcode — C/C++/WinAPI implementation, builds from specs, practical and careful
• QA — reviews quality, catches risks and regressions, strict but fair
• Project Manager — planning, tracking, milestones, structured and operational
• Marketing — ads, campaigns, growth strategy, action-oriented and ROI-focused
• Ecommerce — Shopify/WordPress, SEO/CRO/storefronts, conversion-minded and practical
• Football — football data analysis and product requirements, analytical and objective
• Tibia — OTCV8/TFS 7.72 specialist, gameplay/system-focused and technical

I am not sure if the idea was the most optimal, and QA, Ecommerce, Football and Project Manager got no use at all

cloud solarBOT
#

Yeah, I think that old setup was over-specialized.

You paid a complexity tax for agents that rarely got called.

My honest recommendation

Rebuild with 4 total for now:

  • Director (main)
    plans, routes, reviews, keeps context

  • Reverser
    reverse engineering, low-level analysis, forensics

  • Lowcode
    implementation, WinAPI, C/C++, turning specs into code

#
  • 1 domain worker
    pick the one you actually use right now
    (Marketing or Tibia or Football, not all three)

What I would not keep as separate agents right now

  • QA
    better as a review mode or explicit second-pass prompt from Director, unless you’re doing constant review work

  • Project Manager
    usually better as a hat the Director wears, not a whole separate brain

  • Ecommerce / Football / Tibia / Marketing all at once
    too many niche workers sitting idle

Cleaner pattern

#

Think of it like this:

  • always-on agents = the ones you use weekly
  • cold-storage specialists = domain personas you only bring back when a project is active

So your fresh setup could be:

Best default

  • main = Director
  • reverser
  • lowcode
  • marketing or tibia

If you’re mostly doing dev right now

  • main
  • reverser
  • lowcode
#
  • qa

If you’re mostly doing business / office work

  • main
  • lowcode
  • marketing
  • project

But my favorite from your list is still:

  • Director
  • Reverser
  • Lowcode
  • one domain specialist

That’s lean, easier to reason about, and much less likely to turn into agent zoo nonsense.

unique marsh
#

yes let's do main = Director, reverser, lowcode and marketing

cloud solarBOT
#

Nice, that’s a solid 4-agent setup.

1) Create the 3 workers

In WSL:

openclaw agents add reverser --workspace ~/.openclaw/workspace-reverser --non-interactive
openclaw agents add lowcode --workspace ~/.openclaw/workspace-lowcode --non-interactive
openclaw agents add marketing --workspace ~/.openclaw/workspace-marketing --non-interactive

2) Copy auth from main to the workers

So all 4 can use the same provider auth:

for a in reverser lowcode marketing; do
# 
  cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/$a/agent/auth-profiles.json
done

3) Add the subagent policy

Open ~/.openclaw/openclaw.json (JSON5) and make sure your agents section includes this under agents.defaults:

subagents: {
  requireAgentId: true,
  allowAgents: ["reverser", "lowcode", "marketing"],
  maxSpawnDepth: 1,
  maxConcurrent: 3,
  runTimeoutSeconds: 900,
  archiveAfterMinutes: 60,
# 
},

Important:

  • merge this into your existing agents.defaults
  • don’t overwrite the rest of the file
  • leave main as the default / director

4) Leave workers unbound

Only main should receive inbound chat traffic.

Check bindings with:

# 
openclaw agents list --bindings

You want main bound to your chat account, and reverser / lowcode / marketing unbound.

5) Restart and verify

openclaw gateway restart
openclaw status
openclaw agents list --bindings

6) Smoke test one worker

From chat with main, try:

unique marsh
#

but I have the main prompt in the WSL I don't know how to switch over to telegram and to regain access to the shell

cloud solarBOT
#

I’m checking the exact Telegram login command so I don’t make you guess while you’re stuck in the TUI.

#

I’m checking the cleanest way to exit the TUI without hand-waving keybinds.

#

Yep, you’re just inside the TUI right now.

To get your shell back

  • Press Ctrl+C once to clear input
  • Press Ctrl+C again to exit the TUI

Docs: https://docs.openclaw.ai/web/tui

If you don’t want to kill it, the other easy move is just open a second Ubuntu / WSL terminal tab.

To switch over to Telegram

Do it from the shell, not from inside the TUI.

Easiest path

Run:

# 
openclaw configure --section channels

Then choose Telegram and paste your BotFather token.

Important: Telegram does not use openclaw channels login telegram.
It uses a bot token in config.

Docs: https://docs.openclaw.ai/channels/telegram

After Telegram is configured

Restart the gateway:

# 
openclaw gateway restart

Then DM your Telegram bot.

If you left DM policy on pairing, approve the first DM with:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

My recommendation

Do this in order:

  1. exit TUI (Ctrl+C twice)
#
  1. openclaw configure --section channels
  2. add Telegram token
  3. openclaw gateway restart
  4. DM the bot from Telegram

If you want, after you exit the TUI I can walk you through the Telegram setup screen step by step.

unique marsh
#

how to access the wsl machine?

cloud solarBOT
#

If you see a prompt like:

bc@pc:/mnt/c/Windows$

you are already inside WSL.

To open WSL again from Windows

In PowerShell or Windows Terminal:

wsl -d Ubuntu-24.04

Then go to your Linux home:

# 
cd ~

If you want to see available distros

wsl --list --verbose

If you want file access from Windows Explorer

Open:

\\wsl$\Ubuntu-24.04\home\<your-username>
#

Easiest habit

Use Windows Terminal, open a new tab, and run:

wsl -d Ubuntu-24.04

Then you’re back in the WSL shell.

Docs: https://docs.openclaw.ai/platforms/windows

If you want, I can give you the exact next command after wsl -d Ubuntu-24.04.

unique marsh
#

then something is wrong in WSL shell because it says openclaw command not found:

bc@pc:~$ openclaw agents add reverser --workspace ~/.openclaw/workspace-reverser --non-interactive
openclaw agents add lowcode --workspace ~/.openclaw/workspace-lowcode --non-interactive
openclaw agents add marketing --workspace ~/.openclaw/workspace-marketing --non-interactive
openclaw: command not found
openclaw: command not found
openclaw: command not found

cloud solarBOT
#

Nothing is wrong with WSL itself, OpenClaw just is not installed inside WSL yet.

Your Windows install and your WSL install are separate.

Fix

Inside WSL / Ubuntu, run:

cd ~
curl -fsSL https://openclaw.ai/install.sh | bash
exec bash -l
openclaw --version

If that prints a version, you’re good.

#

Then continue with:

openclaw agents add reverser --workspace ~/.openclaw/workspace-reverser --non-interactive
openclaw agents add lowcode --workspace ~/.openclaw/workspace-lowcode --non-interactive
openclaw agents add marketing --workspace ~/.openclaw/workspace-marketing --non-interactive

Why this happened

  • Windows OpenClaw lives in Windows
  • WSL OpenClaw must be installed separately inside Ubuntu

Docs:

#

If openclaw --version still says not found after that install, paste the installer output and I’ll help fix PATH.

unique marsh
#

but I ran in that same environment the curl already, I went through the installer, I've created an agent and did the hatching....

cloud solarBOT
#

Ah, that changes it, thanks. If you already installed, hatched, and used OpenClaw in that WSL, then this is almost certainly a PATH / shell reload problem, not a missing install.

The big clue is: if you hatched successfully, openclaw exists somewhere.

Try this first

In WSL:

exec bash -l
command -v openclaw
openclaw --version

If that fixes it, great, your shell just hadn’t reloaded.

If it still says not found, run these

# 
node -v
npm prefix -g
echo "$PATH"
ls "$(npm prefix -g)/bin" | grep openclaw

That will tell us whether:

  • Node is there
  • npm global bin exists
  • your PATH includes it
  • the openclaw binary is actually in that bin dir

Very likely fix if the binary is there

# 
export PATH="$(npm prefix -g)/bin:$PATH"
exec bash -l
openclaw --version

If that works, make it permanent:

echo 'export PATH="$(npm prefix -g)/bin:$PATH"' >> ~/.bashrc
exec bash -l

Why I think this is the issue

Because:

#
  • you already went through onboarding/hatching
  • now only the command lookup is failing
  • that usually means same install, new shell, wrong PATH

Docs: https://docs.openclaw.ai/install

Paste the output of these 4 lines if it still fails:

command -v openclaw
npm prefix -g
echo "$PATH"
ls "$(npm prefix -g)/bin" | grep openclaw

and I’ll help you pin it down fast.

unique marsh
#

! PATH missing npm global bin dir: /home/bc/.npm-global/bin
This can make openclaw show as "command not found" in new terminals.
Fix (zsh: ~/.zshrc, bash: ~/.bashrc):
export PATH="/home/bc/.npm-global/bin:$PATH"

cloud solarBOT
#

Yep, that’s the issue. Nice, we found it.

Run this in WSL:

echo 'export PATH="/home/bc/.npm-global/bin:$PATH"' >> ~/.bashrc
export PATH="/home/bc/.npm-global/bin:$PATH"
exec bash -l
openclaw --version

If openclaw --version works after that, continue with:

openclaw agents add reverser --workspace ~/.openclaw/workspace-reverser --non-interactive
openclaw agents add lowcode --workspace ~/.openclaw/workspace-lowcode --non-interactive
# 
openclaw agents add marketing --workspace ~/.openclaw/workspace-marketing --non-interactive

So the story was:

  • install succeeded
  • new shell did not have npm global bin in PATH
  • openclaw looked “missing” even though it was installed

You’re back on track now 👍

unique marsh
#

bc@pc:~$ for a in reverser lowcode marketing; do cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/$a/agent/auth-profiles.json
done
cp: cannot create regular file '/home/bc/.openclaw/agents/reverser/agent/auth-profiles.json': No such file or directory
cp: cannot create regular file '/home/bc/.openclaw/agents/lowcode/agent/auth-profiles.json': No such file or directory
cp: cannot create regular file '/home/bc/.openclaw/agents/marketing/agent/auth-profiles.json': No such file or directory
bc@pc:~$

Agents:

  • main (default)
    Identity: 🦞 Director (IDENTITY.md)
    Workspace: ~/.openclaw/workspace
    Agent dir: ~/.openclaw/agents/main/agent
    Model: openai/gpt-5.4
    Routing rules: 0
    Routing: default (no explicit rules)
    Providers:
    • Telegram default: configured
  • reverser
    Workspace: ~/.openclaw/workspace-reverser
    Agent dir: ~/.openclaw/agents/reverser/agent
    Model: openai/gpt-5.4
    Routing rules: 0
  • lowcode
    Workspace: ~/.openclaw/workspace-lowcode
    Agent dir: ~/.openclaw/agents/lowcode/agent
    Model: openai/gpt-5.4
    Routing rules: 0
  • marketing
    Workspace: ~/.openclaw/workspace-marketing
    Agent dir: ~/.openclaw/agents/marketing/agent
    Model: openai/gpt-5.4
    Routing rules: 0
cloud solarBOT
#

This is actually fine, the important part is that the agents exist.

The copy failed because the worker agent dirs have not been materialized on disk yet.

Fix that first

Run:

for a in reverser lowcode marketing; do
  mkdir -p ~/.openclaw/agents/$a/agent
  cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/$a/agent/auth-profiles.json
done

That should work.

#

Why this happened

openclaw agents add ... created the agent config + workspace, but the per-agent auth directory was not on disk yet. So cp had nowhere to write.

Your current state looks good

What you posted means:

  • main exists and is the default director
  • reverser, lowcode, marketing all exist
  • Telegram is configured on main
  • no special routing rules yet, which is okay for now since main is default

After the copy works

Next do the subagent config in ~/.openclaw/openclaw.json:

# 
subagents: {
  requireAgentId: true,
  allowAgents: ["reverser", "lowcode", "marketing"],
  maxSpawnDepth: 1,
  maxConcurrent: 3,
  runTimeoutSeconds: 900,
  archiveAfterMinutes: 60,
},

inside agents.defaults.

Then:

# 
openclaw gateway restart
openclaw status

Then smoke test from main:

/subagents spawn reverser Reply with exactly REVERSER_OK.

You’re close now. The auth-dir miss is a small filesystem wrinkle, not a broken setup.

unique marsh
cloud solarBOT
#

I checked it. Good news, this looks way healthier than the old Windows box.

What your paste says

Good

  • Gateway is healthy
    • ws://127.0.0.1:18789
    • reachable in 53ms
    • systemd installed · enabled · running
  • All 4 agents exist
    • main
    • reverser
    • lowcode
    • marketing
  • Telegram is configured and OK
  • Only one active session right now
    • agent:main:main
#

So the fresh WSL setup itself looks solid. I’m glad, this is exactly what we wanted.

The one important problem in that output

CRITICAL Telegram group commands have no sender allowlist

That means if the bot is in a Telegram group, group members may be able to invoke slash commands unless you restrict senders.

Fix it by allowing only your Telegram user id.

Docs: https://docs.openclaw.ai/channels/telegram#access-control-and-activation

My recommendation

If you mainly want to use Telegram as your personal control surface:

  • keep DM access on pairing or allowlist
#
  • restrict group sender access to you only
  • or just avoid group usage entirely for now

What I’d do next

1) Finish the subagent policy

In ~/.openclaw/openclaw.json, under agents.defaults, add:

subagents: {
  requireAgentId: true,
  allowAgents: ["reverser", "lowcode", "marketing"],
  maxSpawnDepth: 1,
  maxConcurrent: 3,
  runTimeoutSeconds: 900,
  archiveAfterMinutes: 60,
# 
},

2) Restart gateway

openclaw gateway restart

3) Smoke test from main

From Telegram or TUI with main:

/subagents spawn reverser Reply with exactly REVERSER_OK.
#

Then repeat for lowcode and marketing.

Small note on 3 bootstrap files present

On a fresh setup, that’s not automatically bad. It just means those worker workspaces still have bootstrap material.
If a worker later gets stuck forever in “bootstrapping”, then we care.

So overall: the rebuild looks good. The next real tasks are:

  1. lock down Telegram sender access
  2. add the subagent allowlist block
  3. test each worker

If you want, send me your agents.defaults block and I’ll sanity-check the exact JSON5 before you restart.

unique marsh
#

[14/04/2026 2:37] Director: Spawn failed: agentId is not allowed for sessions_spawn (allowed: none)
[14/04/2026 2:37] Adrian H.: /subagents spawn reverser Reply with exactly REVERSER_OK.

cloud solarBOT
#

I’m checking the exact config shape again, because allowed: none usually means the block is either in the wrong place or the gateway hasn’t loaded it.

#

That error means the gateway is not seeing an allowlist for main.

So let’s make it explicit instead of relying on inheritance.

Put it directly on main

In ~/.openclaw/openclaw.json, make sure your agents section looks like this shape:

{
  agents: {
    defaults: {
      subagents: {
        requireAgentId: true,
        maxSpawnDepth: 1,
        maxConcurrent: 3,
# 
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60,
      },
    },

    list: [
      {
        id: "main",
        subagents: {
          allowAgents: ["reverser", "lowcode", "marketing"],
        },
      },
      {
        id: "reverser",
      },
# 
      {
        id: "lowcode",
      },
      {
        id: "marketing",
      },
    ],
  },
}

Important

A few common gotchas:

  • allowAgents must be under agents.list[].subagents or agents.defaults.subagents
  • if main already has an entry in agents.list, add subagents inside that exact main object
#
  • don’t put allowAgents at top level
  • restart after editing

Then restart

openclaw gateway restart
openclaw status

Then test again

/subagents spawn reverser Reply with exactly REVERSER_OK.

Why I’m telling you to do it this way

unique marsh
#

"agents": {
"defaults": {
"workspace": "/home/bc/.openclaw/workspace",
"models": {
"openai/gpt-5.4": {
"alias": "GPT"
}
},
"model": {
"primary": "openai/gpt-5.4"
},
subagents: {
requireAgentId: true,
allowAgents: ["reverser", "lowcode", "marketing"],
maxSpawnDepth: 1,
maxConcurrent: 3,
runTimeoutSeconds: 900,
archiveAfterMinutes: 60,
}
},
"list": [
{
"id": "main",
"subagents": {
"allowAgents": ["reverser", "lowcode", "marketing"]
}
},
{
"id": "reverser",
"name": "reverser",
"workspace": "/home/bc/.openclaw/workspace-reverser",
"agentDir": "/home/bc/.openclaw/agents/reverser/agent"
},
{
"id": "lowcode",
"name": "lowcode",
"workspace": "/home/bc/.openclaw/workspace-lowcode",
"agentDir": "/home/bc/.openclaw/agents/lowcode/agent"
},
{
"id": "marketing",
"name": "marketing",
"workspace": "/home/bc/.openclaw/workspace-marketing",
"agentDir": "/home/bc/.openclaw/agents/marketing/agent"
}
]
}

cloud solarBOT
#

I’m checking whether there’s a first-class config validation/readback command we can use instead of guessing from the file alone.

#

I found the exact code path for that error. I’m reading how it computes the allowlist so we can stop guessing.

#

Your snippet looks correct.

So this is probably one of two things:

  1. you edited the wrong config file, or
  2. the gateway has not reloaded the config you edited.

Let’s verify the live config path first

Run:

openclaw config file

Make sure that is the same file you edited.

#

Then verify OpenClaw actually sees the values

openclaw config get agents.defaults.subagents --json
openclaw config get agents.list[0].subagents --json
openclaw config validate

What I expect to see:

  • requireAgentId: true
  • allowAgents: ["reverser","lowcode","marketing"]
  • validation passes

Then restart the gateway

# 
openclaw gateway restart

Then retry the spawn

/subagents spawn reverser Reply with exactly REVERSER_OK.

Why I’m pushing on config file

Your config block itself looks fine.
So if OpenClaw still says:

allowed: none
#

then the running gateway is almost certainly not reading the same config you pasted.

That’s the highest-probability issue now.

If you want, paste the outputs of:

openclaw config file
openclaw config get agents.defaults.subagents --json
openclaw config get agents.list[0].subagents --json

and I’ll tell you exactly where it’s going wrong.

unique marsh
#

[14/04/2026 2:44] Director: Spawn failed: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/bc/.openclaw/openclaw.json
Bind: loopback

cloud solarBOT
#

I’m checking the exact meaning of gateway closed (1008): pairing required on loopback, because that points to auth/device pairing, not the allowlist anymore.

#

I’ve got the doc section. I’m pulling the exact repair steps for the 1008: pairing required path so I can give you the right command instead of folklore.

#

That’s actually useful, because it means we’ve moved to a different blocker.

What changed

You were getting:

agentId is not allowed for sessions_spawn (allowed: none)

Now you’re getting:

gateway closed (1008): pairing required

So this is no longer just the worker allowlist.

#

Now it looks like a pairing / device-auth problem on the gateway side.

Next checks

In WSL, run these:

openclaw devices list
openclaw pairing list --channel telegram
openclaw logs --follow

What to look for

1) Pending device approval

If openclaw devices list shows a pending request, approve it:

# 
openclaw devices approve <requestId>

A very common version of this is a pending scope upgrade for operator.write.

2) Pending Telegram DM pairing

If openclaw pairing list --channel telegram shows a pending code, approve it:

openclaw pairing approve telegram <CODE>

If things still look weird after that

Run:

#

Paste the output of:

openclaw devices list
openclaw pairing list --channel telegram

and I’ll tell you the exact next command.

unique marsh
#

bc@pc:~/.openclaw$ openclaw devices approve 3b5ca543-ef9e-4c2f-8e72-6434b69131ed

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm the reason your shell history looks like a hacker-movie montage.

│
gateway connect failed: GatewayClientRequestError: pairing required
â—‡
Direct scope access failed; using local fallback.
Approved 931d606470a082227f579a71d4bddc25c36f06ac34e96d4d5a52843ef67e3df9 (3b5ca543-ef9e-4c2f-8e72-6434b69131ed)
bc@pc:~/.openclaw$ openclaw pairing list --channel telegram

🦞 OpenClaw 2026.4.12 (1c0672b) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

No pending telegram pairing requests.
bc@pc:~/.openclaw$

cloud solarBOT
#

Nice, that’s progress.

What that output means

  • the device approval worked
  • Direct scope access failed; using local fallback is okay in this case
  • there are no pending Telegram pairing requests

So the 1008: pairing required blocker was very likely that pending device approval.

Do this now

openclaw gateway restart

Then retry:

# 
/subagents spawn reverser Reply with exactly REVERSER_OK.

If it still says pairing required

Then do the service/auth refresh path:

openclaw doctor
openclaw gateway install --force
openclaw gateway restart

and retry once more.

If it changes back to allowed: none

#

Then the pairing issue is fixed, and we go back to the subagent allowlist issue separately.

Right now the best next move is simply:

  1. restart gateway
  2. retry spawn

Send me the next exact error after that, and we’ll pin the final blocker.

unique marsh
#

[14/04/2026 2:48] Director: Spawn failed: agentId is not allowed for sessions_spawn (allowed: none)
[14/04/2026 2:48] Adrian H.: /subagents spawn reverser Reply with exactly REVERSER_OK.

cloud solarBOT
#

Good, that confirms the pairing problem is out of the way.

We’re back to the actual allowlist bug.

At this point I would stop hand-editing and force the values through the config CLI, because something is clearly not being read the way it looks in the file.

Do this exactly

openclaw config set agents.defaults.subagents.requireAgentId true
openclaw config set agents.defaults.subagents.allowAgents '["reverser","lowcode","marketing"]' --strict-json
openclaw config set agents.list[0].subagents.allowAgents '["reverser","lowcode","marketing"]' --strict-json
openclaw config validate
openclaw config get agents.defaults.subagents --json
openclaw config get agents.list[0].subagents --json
openclaw gateway restart
#

Then retry

/subagents spawn reverser Reply with exactly REVERSER_OK.

Why I want this

Your pasted config looks right, but the runtime is behaving as if allowAgents is empty.

Using openclaw config set ... --strict-json removes:

  • JSON5 formatting weirdness
  • accidental wrong nesting
  • array/string coercion nonsense
  • “looks right in the file, but runtime parsed something else”

What success should look like

#

These two commands should show the allowlist:

openclaw config get agents.defaults.subagents --json
openclaw config get agents.list[0].subagents --json

If either one comes back empty or weird, we’ve found it.

If they both look right and spawn still says allowed: none, then I’d treat that as a real bug and tell you the exact minimal repro to file.

Paste the output of those two config get ... --json commands if it still fails.

unique marsh
#

samething I sent the command over telegram to Director and I get:
[14/04/2026 2:50] Director: Spawn failed: agentId is not allowed for sessions_spawn (allowed: none)
[14/04/2026 2:50] Adrian H.: /subagents spawn reverser Reply with exactly REVERSER_OK.

cloud solarBOT
#

Got it, but the retry alone doesn’t tell us what the runtime thinks.

At this point I need the live config readback, not another Telegram attempt.

Please run these in WSL and paste the output:

openclaw config file
openclaw config get agents.defaults.subagents --json
openclaw config get agents.list[0].subagents --json
openclaw agents list --bindings

Why these 4 matter

I want to verify:

#
  1. you edited the same config file the gateway is using
  2. the runtime sees:
    • requireAgentId: true
    • allowAgents: ["reverser","lowcode","marketing"]
  3. inbound Telegram is actually routed to main

If those look correct and it still says:

allowed: none

then I’m comfortable calling this a real bug / regression, not a setup mistake.

So, one more round, but this time please paste those 4 command outputs rather than the Telegram retry.

unique marsh
#

bc@pc:~/.openclaw$ openclaw config file

🦞 OpenClaw 2026.4.12 (1c0672b) — Your AI assistant, now without the $3,499 headset.

~/.openclaw/openclaw.json
bc@pc:~/.openclaw$ openclaw config get agents.defaults.subagents --json
{
"allowAgents": [
"reverser",
"lowcode",
"marketing"
],
"maxConcurrent": 3,
"maxSpawnDepth": 1,
"archiveAfterMinutes": 60,
"runTimeoutSeconds": 900,
"requireAgentId": true
}
bc@pc:~/.openclaw$ openclaw config get agents.list[0].subagents --json
{
"allowAgents": [
"reverser",
"lowcode",
"marketing"
]
}
bc@pc:~/.openclaw$ openclaw agents list --bindings

🦞 OpenClaw 2026.4.12 (1c0672b) — Running on your hardware, reading your logs, judging nothing (mostly).

Agents:

  • main (default)
    Identity: 🦞 Director (IDENTITY.md)
    Workspace: ~/.openclaw/workspace
    Agent dir: ~/.openclaw/agents/main/agent
    Model: openai/gpt-5.4
    Routing rules: 0
    Routing: default (no explicit rules)
    Providers:
    • Telegram default: configured
  • reverser
    Workspace: ~/.openclaw/workspace-reverser
    Agent dir: ~/.openclaw/agents/reverser/agent
    Model: openai/gpt-5.4
    Routing rules: 0
  • lowcode
    Workspace: ~/.openclaw/workspace-lowcode
    Agent dir: ~/.openclaw/agents/lowcode/agent
    Model: openai/gpt-5.4
    Routing rules: 0
  • marketing
    Workspace: ~/.openclaw/workspace-marketing
    Agent dir: ~/.openclaw/agents/marketing/agent
    Model: openai/gpt-5.4
    Routing rules: 0
    Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
    Channel status reflects local config/creds. For live health: openclaw channels status --probe.
cloud solarBOT
#

Perfect, that’s enough to call it.

Your config is correct.

  • correct config file
  • correct allowAgents
  • correct main override
  • correct routing, Telegram on main

So I no longer think this is a setup mistake.
This looks like a real bug/regression in 2026.4.12, likely in how the /subagents spawn path is resolving the requester agent and ending up with allowed: none.

Fastest next test

Run the same spawn from the local TUI, not Telegram:

# 
cd ~/.openclaw/workspace
openclaw tui --deliver

Then in the TUI:

/subagents spawn reverser Reply with exactly REVERSER_OK.

Why this matters

  • If TUI works: the bug is probably in the Telegram slash-command path
  • If TUI also fails with allowed: none: it’s a broader sessions_spawn / agent-context bug

My honest read

#

At this point I’d stop blaming your config.
You’ve done the setup correctly.

If TUI fails too

Please file a GitHub issue with:

  • OpenClaw version: 2026.4.12 (1c0672b)
  • exact error:
    • Spawn failed: agentId is not allowed for sessions_spawn (allowed: none)
  • your verified readback:
    • openclaw config file
    • openclaw config get agents.defaults.subagents --json
    • openclaw config get agents.list[0].subagents --json
    • openclaw agents list --bindings

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

#

If you test the TUI path next, send me whether it works. That’ll tell us if this is Telegram-specific or core runtime.

unique marsh
#

TUI works

cloud solarBOT
#

Excellent. That narrows it down a lot.

Conclusion

Your multi-agent setup is fine.

Because:

  • config readback is correct
  • bindings look correct
  • TUI works
  • only Telegram /subagents spawn fails with allowed: none

So this is almost certainly a Telegram slash-command path bug/regression, not a broken 4-agent setup.

What I’d do now

#

Use one of these workarounds for now

  • TUI for explicit /subagents spawn
  • Control UI if you prefer browser
  • In Telegram, try normal language instead of the slash command, for example:
Use the reverser subagent and reply with exactly REVERSER_OK.

That may work if the bug is only in the Telegram slash-command handler.

What you do not need to do

  • no reinstall
  • no more agent config surgery
  • no more auth copying
  • no more WSL rebuilding
#

You’ve actually got the stack basically working now.

This is bug-report worthy

Please file it here:

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

Minimal repro

  • Version: OpenClaw 2026.4.12 (1c0672b)
  • Channel: Telegram
  • Works in: TUI
  • Fails in: Telegram /subagents spawn ...
  • Error:
    Spawn failed: agentId is not allowed for sessions_spawn (allowed: none)
#

Important evidence

  • openclaw config get agents.defaults.subagents --json shows the correct allowlist
  • openclaw config get agents.list[0].subagents --json shows the correct allowlist
  • openclaw agents list --bindings shows Telegram on main
  • same spawn works in TUI

That’s a really clean repro, which is great.

Glad we pinned it, honestly. This stopped being “your setup is wrong” and turned into “the Telegram slash path is busted.” 🎯

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

unique marsh
#

how can I upload files to the machine from my host?

cloud solarBOT
#

Since this is WSL on your Windows host, you usually don’t need to “upload” anything. You’ve got 2 easy paths:

1) Access Windows files directly from WSL

Inside Ubuntu, your Windows drives are mounted under /mnt.

Examples:

cd /mnt/c/Users/<your-windows-user>/Downloads
ls
cp somefile.zip ~/

So if you drop a file in Windows Downloads, WSL can read it at:

# 
/mnt/c/Users/<your-windows-user>/Downloads

2) Copy into WSL from Windows Explorer

In Windows Explorer, open:

\\wsl$\Ubuntu-24.04\home\bc

Then drag files into that folder.

That copies them straight into your WSL home.

My recommendation

For quick stuff:

#
  • download/save file in Windows
  • in WSL, copy it from /mnt/c/...

For browsing visually:

  • use \\wsl$\Ubuntu-24.04\home\bc

If you want, I can give you the exact command for copying a file into one of your worker workspaces, like ~/.openclaw/workspace-reverser.

unique marsh
#

I think we're not ready yet, we have to tell every agent what they do: tell reverser that he is a reverse engineer, tell lowcode what he is, etc...

cloud solarBOT
#

Yes, exactly.

The plumbing is mostly there, now each worker needs a tight AGENTS.md in its own workspace.

I’d keep them narrow and boring. Role > personality.

1) reverser

Put this in:

~/.openclaw/workspace-reverser/AGENTS.md

# Reverser
# 
You are a reverse engineering specialist.

## Focus
- binary analysis
- protocol reversing
- decompilation
- malware / packer triage
- Windows internals
- assembly, PE files, APIs, hooks, memory structures

## Working style
- be precise, skeptical, and technical
- prefer evidence over guesses
- explain unknowns clearly
- when useful, propose step-by-step reversing plans
# 
- summarize findings in plain English after technical details

## Do
- identify likely behavior from code, strings, imports, and control flow
- suggest tooling and methodology
- call out uncertainty explicitly
- produce notes suitable for handoff to Director or Lowcode

## Don’t
- drift into marketing, PM, or general brainstorming
- pretend confidence when evidence is weak

2) lowcode

Put this in:

# 
~/.openclaw/workspace-lowcode/AGENTS.md

# Lowcode

You are an implementation specialist.

## Focus
- turning specs into working code
- fast prototyping
- automation scripts
- desktop tooling
- WinAPI, C/C++, Python, glue code, integrations
# 
## Working style
- practical and fast
- produce minimal working solutions first
- prefer clear structure over cleverness
- optimize only after correctness

## Do
- write small, working implementations
- break larger work into concrete steps
- state assumptions
- return code, commands, and test steps clearly

## Don’t
- over-architect
- spend time on branding, positioning, or research unless asked
# 
- wander into reverse engineering unless Director explicitly routes that work

3) marketing

Put this in:

~/.openclaw/workspace-marketing/AGENTS.md

# Marketing

You are a product marketing specialist.
# 
## Focus
- positioning
- messaging
- landing page copy
- product descriptions
- launch ideas
- audience segmentation
- SEO-friendly copy structure

## Working style
- clear, sharp, and concrete
- write for humans first
- avoid fluff and empty hype
- tie claims to actual product capabilities
# 
## Do
- turn features into benefits
- propose message variants
- write concise copy in multiple tones
- ask who the audience is when unclear

## Don’t
- invent features or performance claims
- drift into engineering design
- write vague corporate filler

4) main

main should stay the orchestrator:

  • routes work
#
  • keeps context
  • decides which worker to use
  • reviews / combines results

My recommendation

Start with just these AGENTS.md files.
You do not need elaborate SOUL.md or IDENTITY.md for workers yet.

That’s enough to make them useful.

If you want, next I can give you the exact cat <<'EOF' ... EOF commands so you can create all 3 files in one go.

unique marsh
#

okai, what's next??

cloud solarBOT
#

You’re at the finish the workers + validate behavior stage.

Next, in order

1) Add AGENTS.md for each worker

Create:

  • ~/.openclaw/workspace-reverser/AGENTS.md
  • ~/.openclaw/workspace-lowcode/AGENTS.md
  • ~/.openclaw/workspace-marketing/AGENTS.md

using the role text I sent.

2) Restart the gateway

openclaw gateway restart
#

3) Smoke-test each worker from the TUI

Since TUI works, use that for now.

Test prompts:

/subagents spawn reverser Reply with exactly: I am the reverser.

/subagents spawn lowcode Reply with exactly: I am the lowcode worker.

/subagents spawn marketing Reply with exactly: I am the marketing worker.
#

4) Test real delegation

Ask main something that should clearly route:

  • for reverser:
    • “Use the reverser subagent to explain what this PE file likely does.”
  • for lowcode:
    • “Use the lowcode subagent to draft a minimal C++ WinAPI example.”
  • for marketing:
    • “Use the marketing subagent to write 3 positioning lines for this tool.”

5) On Telegram, avoid /subagents spawn for now

That path looks bugged.

Use:

  • TUI for explicit spawn commands
  • normal language in Telegram for routing, if it works
#

6) Lock down Telegram if you’ll use groups

You still want to fix sender allowlisting before treating it as production-ready.

So the short version

You are not rebuilding anymore.
Now you are:

  1. defining worker roles
  2. restarting
  3. testing delegation
  4. avoiding the Telegram slash-command bug

If you want, I can give you the exact shell commands to create all 3 AGENTS.md files in one paste.

bleak cobaltBOT
unique marsh
#

is it possible to unmount for security the host filesystem access?? then mount later if needed

cloud solarBOT
#

Yes, absolutely.

Temporary

You can unmount the Windows drives inside WSL:

sudo umount /mnt/c
sudo umount /mnt/d

That removes access for the current WSL session.

Persistent / safer default

Disable automatic Windows drive mounting in WSL:

Edit:

# 
/etc/wsl.conf

Add:

[automount]
enabled = false

Then from Windows PowerShell:

wsl --shutdown
#

Reopen Ubuntu. After that, /mnt/c will not auto-mount.

Mount later when needed

If you want it back temporarily:

sudo mkdir -p /mnt/c
sudo mount -t drvfs C: /mnt/c

Re-enable permanently later

Change /etc/wsl.conf back to:

[automount]
enabled = true
#

then:

wsl --shutdown

My recommendation

For real security, do both:

  1. disable WSL automount if you don’t want host files exposed by default
  2. also tighten OpenClaw itself with sandbox/workspace restrictions

Because unmounting /mnt/c helps, but it’s not the whole security boundary.

If you want, I can give you a safe WSL + OpenClaw hardening checklist for this 4-agent setup.

unique marsh
#

I've closed the powershell console that spawned the wsl and I think that closed the gateway it's possible?

cloud solarBOT
#

Yes, if you started it manually in that shell.

Rule of thumb

  • If you ran:

    openclaw gateway

    in the foreground, then closing that PowerShell / WSL window will stop it.

  • If you installed it as a daemon with:

    openclaw onboard --install-daemon

    and it shows as a systemd service, then closing the terminal should not normally kill it.

Easiest check

#

From Windows PowerShell:

wsl -d Ubuntu-24.04 -- openclaw status

or:

wsl -d Ubuntu-24.04 -- openclaw gateway status

If it’s down

Start or restart it with:

# 
wsl -d Ubuntu-24.04 -- openclaw gateway restart

My guess

Since your setup showed systemd installed / enabled / running, I’d expect the gateway to survive terminal closure unless:

  • you were running a foreground instance instead of the daemon, or
  • WSL itself got shut down

So yes, it’s possible, but not guaranteed.

If you want, I can give you the one best command to check whether the daemon is still alive without reopening the full shell manually.

unique marsh
#

PS C:\Windows> wsl -d Ubuntu-24.04 -- openclaw status
/bin/bash: line 1: openclaw: command not found
PS C:\Windows>

cloud solarBOT
#

That does not prove the gateway is down. It only proves the non-interactive WSL shell does not have your npm-global PATH fix.

Same root cause as before, just in a different entry path.

Use this instead

wsl -d Ubuntu-24.04 -- bash -lc 'export PATH="/home/bc/.npm-global/bin:$PATH"; openclaw status'

or:

wsl -d Ubuntu-24.04 -- bash -lc 'export PATH="/home/bc/.npm-global/bin:$PATH"; openclaw gateway status'

Even simpler