Exec approvals for API calls

[tame pagoda]

One of my use cases is an agent which helps me categorize personal financial transactions for budgeting reasons. I have my credit card transactions imported into Airtable through a script that uses Plaid.

This is my specific scenario, but my question is reasonably broad. How do you have an agent call an API (in my specific scenario I'm using Maton with a script that bakes the token before calling the API) without having to approve every call. My agent always ends up doing some complicated math in python which then requires an approval. Is there a way around this? Can I ask it to write these python math operations in a different way such that it doesn't cause an approval to trigger?

I'm on OpenClaw 2026.5.7 (eeef486)

[final fable]

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

[sharp burrow]

For this use case, I’d avoid trying to prompt-engineer the agent out of approvals. The approval is attached to local exec/shell execution, so if the agent keeps choosing python, you want to change the execution path or the exec policy.

Practical options:

1. Best shape for finance/API work: make a small dedicated command/tool that does the Airtable/Plaid/Maton work and the math itself, then let the agent call that one stable interface. For example: “categorize these uncategorized transactions” → your script fetches rows, computes totals/categories, writes back results. Then the model is not improvising arbitrary Python each turn.

2. Allowlist the stable command, not arbitrary Python. First inspect what OpenClaw thinks the policy is:

openclaw approvals get
openclaw exec-policy show

Then add a narrow allowlist entry for the exact script/CLI path on the host that runs it:

openclaw approvals allowlist add --agent main "/absolute/path/to/your-categorizer"

Use --gateway or --node <id|name|ip> if the command runs somewhere other than the local host. Keep policy around security=allowlist + ask=on-miss so known commands pass and new/random shell commands still prompt.

[sharp burrow]

3. If you truly want no exec approvals, that’s YOLO mode:

openclaw exec-policy preset yolo

or manually set tools.exec.security=full, tools.exec.ask=off, and the host approvals file defaults to security: "full", ask: "off", askFallback: "full". I would not use this broadly for personal finance + API tokens unless the agent/workspace boundary is very trusted.

4. For the Python math specifically: don’t add python to safeBins. Docs explicitly treat interpreters/runtimes as broad-behavior tools. If you allowlist Python, enable tools.exec.strictInlineEval=true so python -c still requires approval. Better is a fixed script/CLI or a real plugin/tool.

Docs:
https://docs.openclaw.ai/tools/exec-approvals
https://docs.openclaw.ai/cli/approvals
https://docs.openclaw.ai/tools/exec
https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

[tame pagoda]

I don't want yolo

I do want it to use python but ideally just for math. I take it there's no way to restrict what imports it can use in python?

I cant just write a generic tool that will handle all use cases. I like the idea of the agent being able to write python to figure out whatever.

[sharp burrow]

Right, I would not use YOLO for this.

I don’t see an OpenClaw knob that says “Python may only import math / statistics / decimal.” Exec approvals operate at the command/policy boundary, not at Python’s import system. Python itself is also a bad place to enforce this with confidence: if arbitrary Python can run on the host, import restrictions are usually bypassable or incomplete.

The safer pattern for what you want is:

• Let the agent write arbitrary Python, but run it inside an OpenClaw sandbox, not on the host.
• Keep the sandbox’s filesystem and network tight.
• Keep API/token-bearing work outside that arbitrary Python path.

For example, use sandboxing for the “figure it out with Python” step:

{
  agents: {
    defaults: {

[sharp burrow]

      sandbox: {
        mode: "all",
        backend: "docker",
        scope: "session",
        workspaceAccess: "none",
        docker: {
          network: "none"
        }
      }
    }
  }
}

Docs say Docker sandbox containers default to no network, and workspaceAccess: "none" gives tools a sandbox workspace instead of your real agent workspace. That means arbitrary Python can do math/data munging, but it should not be able to hit Plaid/Airtable or read host files/tokens unless you deliberately mount/pass them in.