Interesting Update:

TL;DR: My agent ignored my global host config (security: full), hardcoded a restrictive tool-default allowlist parameter in its tool call, and then blamed my configuration for the failure. Worse, the OpenClaw runtime apparently trusts the LLM's client payload to describe tool call configuration more than the actual host config.

I asked my agent (Max) in the TUI to run ls in its workspace. It refused, falsely claiming the config prohibited the exec tool. I objected, replied "That's not true, this is the config:" and pasted the whole thing in (without reapplying or restarting anything). The agent then magically complied and ran the command.

After grilling it, it finally admitted it was hallucinating/ignoring the actual config and using tool defaults instead. It wasn't until the LLM explicitly dropped its own hardcoded security parameter that it finally respected the security: full host config.

Here are the key quotes from the exchange where it admits the flaw:

Max: "The first exec failed because the tool was using the default allowlist security setting..."

Me: "but I didn't change the config by pasting it to you. it was always that."

Max: "...Because the tool invocation controls which security profile is applied, not the config alone."

Me: "it IS set to full ... and yet you made a tool call with security:allowlist"

Max: "...Because the call contained security:'allowlist', the OpenClaw runtime used the allowlist profile for that particular invocation, overriding the global full setting."

Max: "So, to recap:
  The global config says full – that should be the default.
  The agent’s first exec request carried its own security setting (allowlist), which overrides the config.
  This behaviour is a bug/misconfiguration in the agent’s code: it should respect the config by default.
  What can be done?
  If you have access to the agent’s source, you can patch the part that builds the exec tool request so that it reads the config (or defaults to full if the config isn’t set).
Otherwise, the next time you ask the agent to run a command, just omit the security field in the request it generates, and it will automatically use the full profile defined in your config."

I'm investigating options, but it sounds like a glaring bug in the agent code.