how to disable "Codex app-server command approval" prompts and always allow

[half sierra]

I am running cron jobs manually in the gateway chat sessions, and I get a huge number of command approval dialogs. I want to know where to disable this behavior in the configuration by allowing the commands to execute.

[lunar quartz]

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

[lime saddle]

First check your version with openclaw --version, because this area has changed recently.

For the current docs, there are two layers that can cause those exec approval prompts:

1. The session/config requested exec policy
2. The host-local approvals policy on the machine actually running commands: ~/.openclaw/exec-approvals.json

For just the current gateway chat session, try:

/exec security=full ask=off

For a persistent gateway-host “always allow” setup:

[lime saddle]

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

Then make the host approval policy match:

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",

[lime saddle]

    askFallback: "full"
  }
}
EOF

Shortcut if you’re setting this on the same local machine:

openclaw exec-policy preset yolo

If the cron jobs run on a node/mac companion app instead of the gateway host, apply approvals to that node instead:

[lime saddle]

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

Docs: https://docs.openclaw.ai/tools/exec-approvals

Security note: this is intentionally YOLO mode. It removes the approval guardrail for host command execution, so I’d only use it on machines/sessions where you’re comfortable with the agent running commands without a human stop point.

[half sierra]

it still asks after enabling preset yolo mode and retarting the gateway

[lime saddle]

Two likely causes:

1. openclaw exec-policy preset yolo is local-only. If the Gateway is on a different machine/process, or commands run on a node/mac companion app, run:

openclaw approvals get --gateway
openclaw approvals get --node <id|name|ip>

and set the actual execution host:

openclaw approvals set --gateway --stdin <<'EOF'
{
  version: 1,
  defaults: {

[lime saddle]

    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

or for node execution:

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {

[lime saddle]

    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

2. If the prompt literally says Codex app-server, that is a separate Codex harness policy, not just OpenClaw exec approvals. Check your config for plugins.entries.codex.config.appServer. For no prompts it should be YOLO-ish:

{
  plugins: {
    entries: {
      codex: {

[lime saddle]

        enabled: true,
        config: {
          appServer: {
            mode: "yolo",
            approvalPolicy: "never",
            sandbox: "danger-full-access",
            approvalsReviewer: "user"
          }
        }
      }
    }
  }
}

If you use a WebSocket app-server, restart that Codex app-server too; restarting only the Gateway may not replace the already-running app-server process.

[lime saddle]

Can you paste:

openclaw --version
openclaw exec-policy show
openclaw approvals get --gateway

and, if applicable, the plugins.entries.codex.config.appServer block with tokens removed? That should show which layer is still asking.

Docs: https://docs.openclaw.ai/tools/exec-approvals and https://docs.openclaw.ai/plugins/codex-harness

[half sierra]

agent:knowledge-base │ security=full │ security=full │ security=full │ requested │
│ │ (tools.exec. │ (~/.openclaw/ │ ask=off │ security │
│ │ security) │ exec-approvals. │ │ applies; │
│ │ ask=off (tools. │ json defaults. │ │ requested │
│ │ exec.ask) │ security) │ │ ask applies │
│ │ │ ask=off (~/. │ │ │
│ │ │ openclaw/exec- │ │ │
│ │ │ approvals.json │ │ │
│ │ │ defaults.ask) │ │ │
│ │ │ askFallback=full │ │ │
│ │ │ (~/.openclaw/ │ │ │
│ │ │ exec-approvals. │ │ │
│ │ │ json defaults. │ │ │
│ │ │ askFallback) │ │ │
│

[lime saddle]

That output means the OpenClaw exec approval layer is already fully open for agent:knowledge-base: security=full, ask=off, askFallback=full.

So if you still get prompts, it’s almost certainly Codex app-server’s native approval policy, or an already-running app-server/session still carrying old policy.

Next checks:

openclaw config get plugins.entries.codex.config.appServer
openclaw config get agents.defaults.embeddedHarness

For Codex app-server YOLO, the app-server block should be equivalent to:

{
  mode: "yolo",

[lime saddle]

  approvalPolicy: "never",
  sandbox: "danger-full-access",
  approvalsReviewer: "user"
}

If you are using transport: "websocket", restart the Codex app-server process too, not just the OpenClaw gateway. Existing Codex threads/app-server sessions may also need a fresh session after policy changes, because thread start/resume carries the approval policy into Codex.

Also useful: run /codex status in that same knowledge-base session and check whether it reports the app-server policy/mode. If it says guardian, on-request, or workspace-write, that’s the layer still prompting.

[half sierra]

openclaw config get plugins.entries.codex.config.appServer
openclaw config get agents.defaults.embeddedHarness

OpenClaw 2026.5.19 (a185ca2) — The lobster in your shell.

Config path not found: plugins.entries.codex.config.appServer. Run openclaw config validate to inspect config shape.

OpenClaw 2026.5.19 (a185ca2) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

Config path not found: agents.defaults.embeddedHarness. Run openclaw config validate to inspect config shape.

[lime saddle]

Those “Config path not found” lines just mean those fields are unset, not necessarily invalid.

On current docs, unset plugins.entries.codex.config.appServer should default to Codex YOLO mode, so if prompts continue I’d explicitly pin it and force a fresh Codex app-server/thread.

Try:

openclaw config set plugins.entries.codex '{
  "enabled": true,
  "config": {
    "appServer": {
      "mode": "yolo",
      "approvalPolicy": "never",
      "sandbox": "danger-full-access",
      "approvalsReviewer": "user"
    }

[lime saddle]

  }
}' --strict-json --merge

openclaw config validate
openclaw gateway restart

If you intentionally want the bundled Codex harness as the embedded runtime for default agents, also set:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"codex","fallback":"none"}' --strict-json
openclaw gateway restart

Then start a fresh OpenClaw session for the cron/manual run. Codex app-server policy is sent on thread start/resume/turn, and an old sidecar thread can keep behaving like the old policy.

[lime saddle]

If you are using a separately launched Codex app-server over websocket, restart that process too. Gateway restart alone will not change a still-running external app-server.

Also run this in the affected session:

/codex status

If it still shows approvalPolicy=on-request, sandbox=workspace-write, or guardian, then we know the Codex harness policy is still being overridden somewhere.

[half sierra]

/codeopenclaw config set agents.defaults.embeddedHarness '{"runtime":"codex","fallback":"none"}' --strict-json
│
◇

OpenClaw 2026.5.19 (a185ca2) — I've seen your commit messages. We'll work on that together.

Error: Config validation failed: agents.defaults.embeddedHarness: Invalid input

[lime saddle]

Yep, skip that embeddedHarness command on 2026.5.19. That knob appears to be version/schema-dependent, and it is only about forcing the embedded harness anyway; it is not the approval switch. My bad for making that part too broad.

For your actual prompt problem, focus on the Codex app-server policy block:

openclaw config set plugins.entries.codex '{
  "enabled": true,
  "config": {
    "appServer": {
      "mode": "yolo",
      "approvalPolicy": "never",
      "sandbox": "danger-full-access",
      "approvalsReviewer": "user"
    }
  }
}' --strict-json --merge

[lime saddle]

openclaw config validate
openclaw gateway restart

Then start a fresh session for the manual cron run. Existing sessions/sidecar Codex threads can keep old approval state.

If that plugins.entries.codex command also fails validation, run:

openclaw config schema | rg -n "appServer|approvalPolicy|approvalsReviewer|embeddedHarness"
openclaw plugins list

and paste the relevant output. On 2026.5.19 the plugin/schema name may differ from the newer docs I’m reading, and we should key off what your installed schema actually exposes.

[half sierra]

seems to be working with the additional config section added. issue is resolved.

[lime saddle]

Glad that fixed it.

Please right-click the solution message → Apps → ✅ Mark Solution when you get a sec. That helps Answer Overflow index the actual fix for the next person who hits the Codex app-server approval layer.