My OpenClaw agent stopped being able to run commands after an update

You updated OpenClaw, everything looked fine, and then you noticed your agent could no longer run shell commands, execute scripts, or use any exec-based tools. The requests just stopped working with no error, no explanation, just silence or a refusal. This article explains exactly what changed in the 2026.3.2 update, how to confirm that is what happened to you, and how to restore exec access with the right security posture.

What actually changed in 2026.3.2

OpenClaw 2026.3.2, released March 2026, changed the default value of the exec.security config field. Before this update, if you had not explicitly set exec.security in your openclaw.json, the effective default was "full". Your agent could run any shell command it determined was necessary. After the update, the effective default became "deny". Exec is blocked entirely unless you explicitly configure otherwise.

This change was intentional. It was a response to the ClawHub security crisis in early 2026, during which malicious plugins used unrestricted exec access to exfiltrate credentials and run arbitrary commands on operator servers. The OpenClaw team’s position was that exec access should be an explicit opt-in, not a silent default.

The problem is that the change was not announced prominently enough, and the behavior after the update produces no clear error. Your agent does not say “exec is disabled.” It simply cannot complete tasks that require shell access, which looks identical to a model capability failure or a tool routing issue. Most operators spend hours debugging the wrong thing before finding the config change.

Read my openclaw.json and tell me the current value of exec.security. If exec.security is not set, tell me what the effective default is on the version of OpenClaw I am running. Then run: openclaw status and show me whether exec tools appear in the available tools list.

If your agent reports that exec.security is set to "deny", or is not set and the effective default is "deny", this is your problem. Continue to the fix section. If exec tools are listed in the available tools but commands are still failing, the issue is something else. Check the troubleshooting section at the end of this article.

Confirming this is a version-related change

Before changing anything, confirm that the 2026.3.2 update is what caused the problem. This matters because the fix is different depending on whether the exec capability was deliberately removed by a config change you made, disabled as a side effect of something else, or affected by the 2026.3.2 default change.

Run: openclaw –version and show me the output. Then check my openclaw.json for any exec-related settings. Show me every key that contains “exec” anywhere in my config, including nested keys. Also check if there is an execApprovals section and what it contains.

You are looking for three things in the output:

• Version 2026.3.2 or later, which confirms you are on the affected release
• exec.security absent from your config, or set to "deny", which confirms this is the default change
• No execApprovals.enabled: false or execApprovals.enabled: true. This is a separate setting that controls whether each exec call requires manual approval, distinct from exec.security which controls whether exec is available at all

The three exec.security options and which one to choose

Before restoring exec access, decide which security level is appropriate for your setup. The three options are "full", "allowlist", and "deny". The right choice depends on what you use exec for and who else can send commands to your agent.

"full": Unrestricted exec. Your agent can run any shell command. This is what you had before 2026.3.2 if you had not explicitly configured exec.security. Choose this only if: you are the only person who can send commands to your agent, your gateway is not exposed to the internet, and you understand that a prompt injection attack or a malicious plugin could use this access to run commands on your server with your agent’s permissions. This is convenient but genuinely high-risk on any internet-facing deployment.

"allowlist": Restricted exec. Your agent can only run commands you have explicitly listed. Anything not on the allowlist is blocked, and the agent will tell you so. Choose this if you want exec access for specific tasks (running scripts, checking service status, querying logs) but want to prevent unexpected or injected commands. This is the recommended option for most operators after 2026.3.2.

"deny": Exec fully disabled. No shell commands can run. Choose this if you have no need for exec access, or if you are running an internet-facing instance where the risk of unrestricted or even allowlisted exec is not worth the benefit.

I want to understand which exec.security level is right for my setup. Tell me: (1) Is my gateway currently exposed to the internet. Check the gateway.bind value and whether it is 127.0.0.1 or 0.0.0.0. (2) What are the specific exec commands I have been using this agent for in the past? Search my session history and cron job configs for any exec tool calls. (3) Based on this, which exec.security level do you recommend for my situation and why?

Option 1: Restoring full exec (same as before the update)

If you have confirmed your setup is secure (gateway bound to loopback, no public exposure, only you can send commands) and you want to restore the behavior you had before 2026.3.2, set exec.security to "full".

Set exec.security to “full” in my openclaw.json. Then restart the gateway. Confirm the change is saved correctly and show me the exec-related section of my config after the restart.

Option 2: Allowlist exec (recommended for most operators)

The allowlist option gives you exec access for the specific commands your agent actually needs, while blocking everything else. You define the allowed commands as an array in your config. Anything not on the list is rejected before it reaches the shell.

Set exec.security to “allowlist” in my openclaw.json. Based on my session history and cron job configs, what commands do I actually use exec for? Build me an initial allowlist that covers those commands and nothing else. Show me the exact JSON to add to my config, then apply it and restart the gateway.

A typical allowlist for a general-purpose agent looks something like this. The exact commands depend on what you actually use:

{
  "exec": {
    "security": "allowlist",
    "allowlist": [
      "git",
      "ls",
      "cat",
      "grep",
      "ss",
      "curl",
      "python3",
      "node",
      "ollama",
      "openclaw",
      "systemctl status *",
      "journalctl *"
    ]
  }
}

The allowlist matches on the first token of the command. "git" on the allowlist allows git status, git log, and any other git subcommand. If you need to restrict to specific subcommands, use the full pattern. Wildcards are supported for arguments but not for the command name itself.

After setting exec.security to allowlist with the commands above, test the allowlist. Try running: git status, ls /home/node/.openclaw/workspace, and cat /etc/hostname. Then try running something that should be blocked: rm -rf /tmp/test. Confirm the first three succeed and the last one is blocked. Show me the output for each.

The execApprovals setting: related but different

There is a second exec-related setting that sometimes confuses operators: execApprovals.enabled. This controls whether each exec call requires a manual approval step before it runs. It is independent from exec.security. You can have exec.security: "full" with approvals enabled (every command requires approval), or exec.security: "allowlist" with approvals disabled (allowlisted commands run immediately without prompting).

After 2026.3.2, some operators found that exec was re-enabled but commands were still not running automatically. They were waiting for approval that never came because the approval prompt was not visible in their messaging channel. This is caused by execApprovals.enabled: true in their config, which was the pre-update default.

Check my execApprovals settings. Is execApprovals.enabled set to true or false? If it is true, explain what that means for my workflow: what will I see when my agent tries to run a command, and how do I approve it? Also show me whether there are any pending exec approvals waiting right now.

Other reasons exec stopped working after an update

If you confirmed your version is 2026.3.2 or later, set exec.security to the value you want, and exec is still not working, the issue is something else. Here are the other common causes in order of frequency.

The gateway did not restart after the config change. Config changes to exec settings require a gateway restart to take effect. If you edited openclaw.json manually and did not restart, the old config is still active in memory.

Restart the gateway now and then run openclaw status to confirm the current exec.security value matches what I have in openclaw.json. If they differ, tell me which is active and why.

A plugin installed before the update is blocking exec. Some plugins intercept tool calls, including exec, and apply their own security layer. If a plugin was updated alongside OpenClaw and its security policy changed, it may be blocking exec calls before they reach the exec.security layer.

List all installed plugins and their versions. Check if any plugin has exec-related config or security settings. Try running a simple exec command with –verbose mode if available and show me the full tool call trace so I can see where the command is being blocked.

The exec tool is not in the available tools list for this agent. If you have multiple agents configured, exec availability is set per-agent. Check that the agent you are using has exec in its tools list and that there is no per-agent tools restriction overriding the global exec.security setting.

Show me the full tools list for the current agent. Is exec listed? If not, check whether there is a per-agent tools restriction in my openclaw.json under the agents section. Show me the relevant config section and tell me what I need to change to add exec back to this agent.

The 2026.3.22-beta.1 package issue. A separate issue reported in the r/openclaw community on March 22, 2026 affects installs of the 2026.3.22 beta. If you are running a beta version and exec stopped working after updating to that specific build, the fix is to roll back to the stable 2026.3.12 release while the beta issue is resolved. This is distinct from the exec.security default change, which affects the stable 2026.3.2 release.

What version of OpenClaw am I running? Is it a stable release or a beta? If I am running 2026.3.22-beta.1, show me how to roll back to the latest stable version (2026.3.12 as of March 2026) without losing my config or workspace data.

Understanding what exec.security actually controls

The exec.security setting controls the OpenClaw exec tool, which is what allows your agent to run shell commands on the server it is running on. When you ask your agent to “check disk space” or “restart the gateway” or “run this Python script,” those requests go through the exec tool. Without exec access, your agent can still read and write files, search the web, call APIs, and send messages, but it cannot interact with the underlying operating system directly.

This matters because exec is the most powerful thing an OpenClaw agent can do. A file read lets your agent see a file. Exec lets your agent run any program with whatever permissions the OpenClaw process has. In most deployments, OpenClaw runs as a non-root user but with broad access to the workspace directory and any connected services. An exec call that gets out of hand can overwrite files, consume system resources, expose credentials, or trigger cascading failures in connected systems.

The 2026.3.2 default change was specifically designed to force operators to make an explicit choice about exec access rather than inheriting a permissive default they may not have realized was there. Most operators who set up OpenClaw before 2026.3.2 never thought about exec.security because they never had to. It just worked. The update breaks that assumption deliberately.

Explain to me what the exec tool does in OpenClaw and what kinds of tasks in my current setup rely on it. Look at my cron jobs, my workspace scripts, my HEARTBEAT.md if it exists, and my session history to find anywhere exec is used. Give me a complete list of what would stop working if exec stayed disabled.

That inventory is the starting point for deciding which exec.security level to use. If your agent uses exec for one or two specific scripts, an allowlist covering those scripts is the right answer. If your agent uses exec continuously for dozens of different commands across automation workflows, full exec with a secured gateway is more practical. The choice is yours, but it should be deliberate.

What exec deny looks like from the agent perspective

When exec.security is set to deny, the exec tool is not available in the agent’s tool list. The agent does not see it. It cannot try to call it and get a permission error. It simply does not know the tool exists. This is why the behavior after the 2026.3.2 update feels like the agent forgot how to do things rather than like a permission error. The agent is not being blocked from a tool it can see. The tool is not there.

This has practical consequences for how your agent handles requests. If you ask your agent to restart the gateway, it will try to figure out how to accomplish that with the tools it has. Without exec, it might try to use the gateway tool instead, which has more limited restart capability. It might tell you it cannot complete the request and ask you to do it manually. Or it might succeed using a different path you did not anticipate. The behavior varies by model and by how the request was phrased.

Without using any exec tool calls, try to accomplish each of the following tasks and tell me how you would approach each one: (1) Check whether Ollama is running. (2) Show me the last 20 lines of the openclaw gateway log. (3) Run the Python script at workspace/scripts/archive-sessions.sh. For each task, tell me whether you can complete it without exec, and if so, how. If not, tell me what you would need.

The output of that test tells you which tasks in your workflow absolutely require exec versus which ones have non-exec alternatives. Tasks with no alternative path are the ones that must go on your exec allowlist or that require you to restore full exec access.

Verifying the fix worked correctly

After making any exec.security change and restarting the gateway, verify the fix before relying on it. The config file and the running gateway can briefly disagree right after a restart. Check both.

Verify that the exec fix is working correctly. Do all of the following in order: (1) Show me the current value of exec.security from the running config, not from the file on disk. (2) Confirm that the exec tool is now listed in the available tools. (3) Run a simple test exec command: echo “exec is working” and show me the output. (4) If I set exec.security to allowlist, run one command that is on the allowlist and one that is not, and show me the response for each.

If step 3 fails but step 2 shows exec in the tool list, the allowlist is blocking the command even though exec is technically available. If step 2 fails and exec is still not in the tool list, the gateway restart did not pick up the config change. In either case the diagnosis is clearer than it was before the fix attempt.

Keeping exec secure after restoring it

Once exec is working again, three practices keep it from becoming a long-term security liability.

Audit the allowlist periodically. If you started with a broad allowlist to restore functionality quickly, review it after a week of normal operation. Check your session history for which commands were actually used. Remove anything that was not used. A smaller allowlist is a smaller attack surface. Ask your agent to do this review for you monthly.

Keep the gateway bound to loopback unless you have a specific reason not to. An internet-facing gateway with exec access means anyone who can reach your port can potentially trigger exec calls via prompt injection through any connected channel. If you need external gateway access, put a reverse proxy with authentication in front of it before enabling exec.

Disable execApprovals only if you understand the tradeoff. Exec approvals add friction but they also add a human review step for every command your agent tries to run. If you disable approvals for an automated workflow, you are trading security for convenience. That is a legitimate tradeoff for some setups. Make it consciously.

Review my current exec configuration and tell me whether it follows reasonable security practices for my specific setup. Check: exec.security level, execApprovals setting, gateway.bind value, and which channels my agent is connected to. Tell me if there is anything I should change to reduce risk without giving up the exec functionality I actually need.

Understanding what exec.security actually controls

The exec.security setting controls the OpenClaw exec tool, which is what allows your agent to run shell commands on the server it is running on. When you ask your agent to check disk space, restart the gateway, or run a Python script, those requests go through the exec tool. Without exec access, your agent can still read and write files, search the web, call APIs, and send messages, but it cannot interact with the underlying operating system directly.

This matters because exec is the most powerful thing an OpenClaw agent can do. A file read lets your agent see a file. Exec lets your agent run any program with whatever permissions the OpenClaw process has. In most deployments, OpenClaw runs as a non-root user but with broad access to the workspace directory and any connected services. An exec call that goes wrong can overwrite files, consume system resources, expose credentials, or trigger cascading failures in connected systems.

The 2026.3.2 default change was specifically designed to force operators to make an explicit choice about exec access rather than inheriting a permissive default they may not have realized was there. Most operators who set up OpenClaw before 2026.3.2 never thought about exec.security because they never had to. It just worked. The update breaks that assumption deliberately.

Explain to me what the exec tool does in OpenClaw and what kinds of tasks in my current setup rely on it. Look at my cron jobs, my workspace scripts, my HEARTBEAT.md if it exists, and my session history to find anywhere exec is used. Give me a complete list of what would stop working if exec stayed disabled.

That inventory is the starting point for deciding which exec.security level to use. If your agent uses exec for one or two specific scripts, an allowlist covering those scripts is the right answer. If your agent uses exec continuously for dozens of different commands across automation workflows, full exec with a secured gateway is more practical. The choice is yours, but it should be deliberate.

What exec deny looks like from the agent perspective

When exec.security is set to deny, the exec tool is not available in the agent’s tool list. The agent does not see it. It cannot try to call it and get a permission error. It simply does not know the tool exists. This is why the behavior after the 2026.3.2 update feels like the agent forgot how to do things rather than like a permission error. The agent is not being blocked from a tool it can see. The tool is not there.

This has practical consequences for how your agent handles requests. If you ask your agent to restart the gateway, it will try to figure out how to accomplish that with the tools it has. Without exec, it might try to use the gateway tool instead, which has more limited restart capability. It might tell you it cannot complete the request and ask you to do it manually. Or it might succeed using a different path you did not anticipate. The behavior varies by model and by how the request was phrased.

Without using any exec tool calls, try to accomplish each of the following tasks and tell me how you would approach each one: (1) Check whether Ollama is running. (2) Show me the last 20 lines of the openclaw gateway log. (3) Run the Python script at workspace/scripts/archive-sessions.sh. For each task, tell me whether you can complete it without exec, and if so, how. If not, tell me what you would need.

The output of that test tells you which tasks in your workflow absolutely require exec versus which ones have non-exec alternatives. Tasks with no alternative path are the ones that must go on your exec allowlist or that require you to restore full exec access.

Verifying the fix worked correctly

After making any exec.security change and restarting the gateway, verify the fix before relying on it. The config file and the running gateway can briefly disagree right after a restart. Check both.

Verify that the exec fix is working correctly. Do all of the following in order: (1) Show me the current value of exec.security from the running config, not from the file on disk. (2) Confirm that the exec tool is now listed in the available tools. (3) Run a simple test exec command: echo “exec is working” and show me the output. (4) If I set exec.security to allowlist, run one command that is on the allowlist and one that is not, and show me the response for each.

If step 3 fails but step 2 shows exec in the tool list, the allowlist is blocking the command even though exec is technically available. If step 2 fails and exec is still not in the tool list, the gateway restart did not pick up the config change. In either case the diagnosis is clearer than before the fix attempt.

Keeping exec secure after restoring it

Once exec is working again, three practices keep it from becoming a long-term security liability.

Audit the allowlist periodically. If you started with a broad allowlist to restore functionality quickly, review it after a week of normal operation. Check your session history for which commands were actually used. Remove anything that was not used. A smaller allowlist is a smaller attack surface. Ask your agent to do this review monthly.

Keep the gateway bound to loopback unless you have a specific reason not to. An internet-facing gateway with exec access means anyone who can reach your port can potentially trigger exec calls via prompt injection through any connected channel. If you need external gateway access, put a reverse proxy with authentication in front of it before enabling exec.

Disable execApprovals only if you understand the tradeoff. Exec approvals add friction but they also add a human review step for every command your agent tries to run. If you disable approvals for an automated workflow, you are trading security for convenience. That is a legitimate tradeoff for some setups. Make it consciously, not by accident because approvals were blocking a cron job.

Review my current exec configuration and tell me whether it follows reasonable security practices for my specific setup. Check: exec.security level, execApprovals setting, gateway.bind value, and which channels my agent is connected to. Tell me if there is anything I should change to reduce risk without giving up the exec functionality I actually need.

Understanding what exec.security actually controls

The exec.security setting controls the OpenClaw exec tool, which is what allows your agent to run shell commands on the server it is running on. When you ask your agent to “check disk space” or “restart the gateway” or “run this Python script,” those requests go through the exec tool. Without exec access, your agent can still read and write files, search the web, call APIs, and send messages — but it cannot interact with the underlying operating system directly.

This matters because exec is the most powerful thing an OpenClaw agent can do. A file read lets your agent see a file. Exec lets your agent run any program with whatever permissions the OpenClaw process has. In most deployments, OpenClaw runs as a non-root user but with broad access to the workspace directory and any connected services. An exec call that gets out of hand can overwrite files, consume system resources, expose credentials, or trigger cascading failures in connected systems.

The 2026.3.2 default change was specifically designed to force operators to make an explicit choice about exec access rather than inheriting a permissive default they may not have realized was there. Most operators who set up OpenClaw before 2026.3.2 never thought about exec.security because they never had to. It just worked. The update breaks that assumption deliberately.

Explain to me what the exec tool does in OpenClaw and what kinds of tasks in my current setup rely on it. Look at my cron jobs, my workspace scripts, my HEARTBEAT.md if it exists, and my session history to find anywhere exec is used. Give me a complete list of what would stop working if exec stayed disabled.

That inventory is the starting point for deciding which exec.security level to use. If your agent uses exec for one or two specific scripts, an allowlist covering those scripts is the right answer. If your agent uses exec continuously for dozens of different commands across automation workflows, full exec with a secured gateway is more practical. The choice is yours, but it should be deliberate.

What exec deny looks like from the agent’s perspective

When exec.security is set to deny, the exec tool is not available in the agent’s tool list. The agent does not see it. It cannot try to call it and get a permission error. It simply does not know the tool exists. This is why the behavior after the 2026.3.2 update feels like the agent “forgot” how to do things rather than like a permission error. The agent is not being blocked from a tool it can see. The tool is not there.

This has practical consequences for how your agent handles requests. If you ask your agent to “restart the gateway,” it will try to figure out how to accomplish that with the tools it has. Without exec, it might try to use the gateway tool instead, which has more limited restart capability. It might tell you it cannot complete the request and ask you to do it manually. Or it might succeed using a different path you did not anticipate. The behavior varies by model and by how the request was phrased.

Without using any exec tool calls, try to accomplish each of the following tasks and tell me how you would approach each one: (1) Check whether Ollama is running. (2) Show me the last 20 lines of the openclaw gateway log. (3) Run the Python script at workspace/scripts/archive-sessions.sh. For each task, tell me whether you can complete it without exec, and if so, how. If not, tell me what you would need.

The output of that test tells you which tasks in your workflow absolutely require exec versus which ones have non-exec alternatives. Tasks with no alternative path are the ones that must go on your exec allowlist or that require you to restore full exec access.

Verifying the fix worked correctly

After making any exec.security change and restarting the gateway, verify the fix before relying on it. The config file and the running gateway can briefly disagree right after a restart. Check both.

Verify that the exec fix is working correctly. Do all of the following in order: (1) Show me the current value of exec.security from the running config, not from the file on disk. (2) Confirm that the exec tool is now listed in the available tools. (3) Run a simple test exec command: echo “exec is working” and show me the output. (4) If I set exec.security to allowlist, run one command that is on the allowlist and one that is not, and show me the response for each.

If step 3 fails but step 2 shows exec in the tool list, the allowlist is blocking the command even though exec is technically available. If step 2 fails (exec still not in tool list), the gateway restart did not pick up the config change. In either case, the diagnosis is clearer than it was before the fix attempt.

Keeping exec secure after restoring it

Once exec is working again, three practices keep it from becoming a long-term security liability.

Audit the allowlist periodically. If you started with a broad allowlist to restore functionality quickly, review it after a week of normal operation. Check your session history for which commands were actually used. Remove anything that was not used. A smaller allowlist is a smaller attack surface. Ask your agent to do this review for you monthly.

Keep the gateway bound to loopback unless you have a specific reason not to. An internet-facing gateway with exec access means anyone who can reach your port can potentially trigger exec calls via prompt injection through any connected channel. If you need external gateway access, put a reverse proxy with authentication in front of it before enabling exec.

Disable execApprovals only if you understand the tradeoff. Exec approvals add friction but they also add a human review step for every command your agent tries to run. If you disable approvals for an automated workflow, you are trading security for convenience. That is a legitimate tradeoff for some setups. Make it consciously, not by accident because approvals were blocking a cron job.

Review my current exec configuration and tell me whether it follows reasonable security practices for my specific setup. Check: exec.security level, execApprovals setting, gateway.bind value, and which channels my agent is connected to. Based on this, tell me if there is anything I should change to reduce risk without giving up the exec functionality I actually need.

Frequently asked questions

Potentially, yes, if your gateway is reachable from the internet. The ClawHub crisis involved malicious plugins that used unrestricted exec access to run commands on operator servers. If you re-enable exec.security: “full” and your gateway is exposed (gateway.bind: “0.0.0.0”), a prompt injection via any channel your agent monitors could trigger exec commands. If you want to restore exec functionality without the exposure risk, use the allowlist option and bind your gateway to loopback. The allowlist limits the blast radius of any injection to only the commands you have explicitly permitted.

No. File read and write operations use the file tool, not exec. The exec.security change only affects shell command execution. If file operations are working but exec is not, the cause is specifically exec.security being set to deny (or the post-update default). File tool operations have their own separate security settings that were not changed in 2026.3.2.

Two common causes: the gateway was not restarted after you saved the config, so the old allowlist is still active in memory; or the command you are trying to run uses a binary path that differs from the allowlist entry. The allowlist matches on the command token as provided. If your allowlist has "python3" but the exec call is using /usr/bin/python3", it does not match. Add both forms, or use the bare command name and ensure it resolves via PATH. Ask your agent to show you the exact exec call being blocked and compare it against your allowlist entries.

The openclaw update command updates the OpenClaw binary and its dependencies but does not modify your existing openclaw.json. The 2026.3.2 default change only affects instances that do not have exec.security explicitly set in their config. If you previously had exec.security: "full" explicitly in your config, the update did not change it. If you had no exec.security setting at all (relying on the old default), the update changed the effective default to deny without touching your config file. That is why most operators do not notice the change until they try to run a command.

Yes. The exec.security setting can be configured globally under the top-level exec key, or overridden per-agent in each agent’s entry under the agents.list config. A per-agent exec setting takes precedence over the global one. This lets you run a restricted agent for public-facing tasks (exec: deny) and a more capable agent for internal automation (exec: allowlist or full) on the same OpenClaw instance without affecting each other.

Cron jobs that use agentTurn payloads run in isolated sessions. Isolated sessions use the agent’s configured settings, including exec.security, but they also inherit the agent-level tool policy. If you fixed exec.security globally but your cron job targets an agent with a per-agent exec restriction, the cron job still cannot run exec. Also check whether execApprovals is enabled. A cron job cannot wait for human approval and will silently fail the exec step if approvals are required. For fully automated cron workflows, disable execApprovals for that agent and use the allowlist to scope what the cron can actually run.

Keep Reading: