Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.claw-link.dev/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw overview illustration This is one of those support issues where the user experience is basically: “I installed the thing, why are the shell tools missing?” And the answer is often an annoying mix of platform capability limits, runtime expectations, and Windows being Windows. If exec-style tools are missing in OpenClaw on Windows or WSL1, the problem is often not that you clicked the wrong button. It is usually one of these:
Warning icon Blunt version: if you are on WSL1, treat that as the prime suspect early. Exec-heavy flows are much happier on WSL2 or a normal Linux host.
  • the current environment does not support the required runtime capability
  • the host/platform combination is limited
  • the session started before tools were refreshed
  • the setup is running on a path where shell/PTY support is unavailable or intentionally disabled

​
Warning icon At a glance

  • Confirm whether you are on Windows, WSL1, or WSL2 before debugging anything else.
  • If this is WSL1, treat that as a serious compatibility warning sign.
  • For exec-heavy workflows, WSL2 or Linux is the sane path.

​
Short version

When people say “exec tools don’t appear,” they usually mean they expected shell-style execution or related runtime capabilities but the current OpenClaw environment is not exposing them. On Windows and especially WSL1, that can happen because capability support is not the same as on a normal Linux host.

​
Why this happens more on Windows and WSL1

OpenClaw features that depend on shell execution, PTY behavior, host process control, or certain runtime assumptions are naturally happiest on a normal supported Unix-like environment. Windows can be more finicky. WSL2 is usually closer to a real Linux environment. WSL1 is where things get especially awkward, because it is not the same thing as a full modern Linux runtime path. That gap can surface as missing exec capabilities, degraded shell behavior, or tools simply not being exposed.

​
Common causes

​
1) The platform/runtime does not expose exec capability there

Some OpenClaw capabilities depend on the host/runtime combination actually supporting them. If the current environment cannot expose shell execution safely or correctly, the tools may be absent rather than half-broken.

​
2) You are on WSL1, not WSL2

This matters more than people want it to. If you are using WSL1, expect more compatibility weirdness. A lot of modern tooling assumes a more complete Linux environment than WSL1 provides.

​
3) The session started before capabilities changed

If you installed, enabled, or changed something and kept testing in the same old chat/session, the tool catalog may not reflect reality yet. Fresh sessions matter.

​
4) The tool is blocked by policy/config, not platform alone

Sometimes the platform gets blamed when the real issue is:
  • config restrictions
  • plugin/tool allowlists
  • disabled runtime features
  • gateway not reloaded after config changes

​
5) You are expecting PTY-required behavior in an environment that cannot provide it

Some agent/tool flows need proper PTY or terminal-like behavior. If the environment cannot provide that cleanly, capability exposure may be limited.

​
What to check first

​
1) Confirm the actual environment

Check whether you are on:
  • native Linux
  • Windows
  • WSL1
  • WSL2
That distinction is not cosmetic.

​
2) Check OpenClaw status

Run: 
openclaw status
If relevant for your setup, also check: 
openclaw gateway status
You want to confirm the runtime is healthy before blaming the tools.

​
3) Start a fresh chat/session

If something was recently enabled, installed, or reconfigured, stop testing in the stale session forever. Start a fresh one.

​
4) Check whether the issue is environment-wide or just one flow

Ask:
  • are all exec/shell tools missing?
  • or only one specific workflow?
  • did this happen after a config change?
  • does the same setup work on Linux or another host?
That helps separate platform limits from config mistakes.

​
Best practical fix if you are on WSL1

Blunt answer: move to WSL2 or a proper Linux host if you want fewer weird capability issues. You can spend time trying to out-negotiate WSL1, but that is usually a bad trade. If exec-heavy workflows matter to you, use the environment that actually wants to support them.

​
If you are on Windows

Windows can work, but if you are hitting repeated shell/runtime capability problems, check whether:
  • a Linux host would be more reliable for that workflow
  • WSL2 is available and better suited
  • the missing tools are actually gated by config/policy rather than OS limits

​
If this started after changing config

Use the boring checklist:
  1. restart the gateway if config changed
  2. check status
  3. start a fresh session
  4. retest
That catches a lot of fake platform mysteries.

​
Common mistakes

​
Assuming Windows, WSL1, and Linux are interchangeable

They are not.

​
Forgetting whether you are on WSL1 or WSL2

This matters a lot here.

​
Testing forever in the same stale chat

Still broken? Yes, because the session is old.

​
Blaming the OS when the real issue is config/policy

Also common.

​
When this page is probably the right match

This article is a good fit if:
  • exec/shell tools are absent
  • you are using Windows or WSL1
  • the environment feels capability-limited compared with Linux
  • support threads keep hinting that host/runtime matters

​
When it might be a different issue

It might instead be:
  • plugin/runtime configuration problem
  • ACP/ACPX setup confusion
  • gateway reload issue
  • session staleness
  • policy restrictions in the current deployment
If so, also check related docs.

​
Final thought

If exec tools are missing on Windows or WSL1, the real answer is often not “you forgot one secret setting.” It is:
this environment may not support the workflow the way you hoped.
Which is annoying, but at least honest. And if the choice is between debugging WSL1 for two more hours or moving to a better-supported environment, I know which one I’d pick.
  • How to reduce token usage in OpenClaw
  • ACP vs normal OpenClaw agents: what’s the difference?
  • How to enable the ACPX plugin in OpenClaw
  • OpenClaw not responding after an update? Start here