How to Configure OpenClaw Strict Inline Eval

strictInlineEval is one of those small OpenClaw settings that prevents a large class of “oops” moments. Exec approvals can allow trusted binaries, but interpreter binaries are special. If node or python is allowlisted, a command like python -c can still evaluate arbitrary inline code. The docs call this out directly and provide tools.exec.strictInlineEval as defense-in-depth.

30-second answer

Set tools.exec.strictInlineEval to true when agents can request host exec and interpreter binaries may be allowlisted. With strict mode on, inline eval forms stay approval-only even if the interpreter itself is trusted. The docs list examples such as python -c, node -e, node --eval, node -p, ruby -e, perl -e, php -r, lua -e, and osascript -e.

Why it matters

Approving a binary is not the same as approving every program that binary can run. Interpreters, shells, and runtime wrappers are designed to load code. A path allowlist can verify which executable is being called, but inline eval shifts the risky part into argv. strictInlineEval keeps that risk visible to the operator.

Where it fits

This setting belongs in host exec approval policy, especially on macOS companion app or node-host workflows where an agent might ask to run real commands. It stacks on top of tool policy and approvals. It does not make unsafe commands safe; it makes ambiguous inline code ask for explicit approval instead of slipping through a broad allowlist.

What still needs review

Even with strictInlineEval, package scripts, loader chains, multi-file runtime invocations, and shell wrappers can carry broader semantics. The advanced docs say approval-backed interpreter and runtime runs are intentionally conservative. When OpenClaw cannot bind exactly one concrete local file for approval, it denies instead of pretending it understands the whole runtime.

Good operating model

Keep routine commands in narrow allowlists, keep interpreters out of safeBins, and require review for inline code. For build systems, prefer sandboxed runs or explicit project scripts where the repository and command are visible. For one-off eval, let the approval prompt do its job.

Playbook angle

The Playbook version is to protect the boring paths. Agents should not need inline eval for normal operations. If they do, that is a signal to turn the one-liner into a reviewed script or a proper tool.

Runbook checklist

Before you automate this, run one small acceptance test with harmless input. Confirm the tool is available to the right agent, the credential is loaded from config or environment, the output shape matches the workflow, and the failure message is understandable to a tired operator. If the feature touches money, public channels, logged-in browsers, host commands, or customer data, put a review step before the side effect. If it only reads data, still record the source and timestamp so future sessions do not treat stale context as fresh truth. Keep the first version narrow, then expand once the logs show the agent is choosing the right tool for the right reason. When the docs are incomplete, prefer a conservative sentence over a clever invented shortcut that future agents cannot reliably verify. Add one monitoring habit as well: after the first real run, check the transcript or logs for missing prerequisites, broad prompts, stale assumptions, and accidental side effects. Tighten the instruction while the failure is fresh. The best OpenClaw workflows improve in small, documented passes instead of one giant rewrite after something breaks in public. For SEO pages, that same discipline matters: do not promise hidden capabilities, paid-provider limits, or setup shortcuts unless the current docs say so. Trust compounds when the guide is accurate even in the boring operational edge cases that matter during real maintenance windows.

Operator note

How to Configure OpenClaw Strict Inline Eval works best when it is written into a small runbook instead of treated as a magic switch. Record who owns the workflow, which config keys are allowed, which credentials are required, what the agent may do without approval, and what counts as a failure. OpenClaw gives agents broad tools, but the reliable version is boring: one source of truth, one verification step, and one rollback path when a provider or channel behaves differently than expected.