openclaw - 💡(How to fix) Fix [Bug]: GPT-5 models inject exec ask/security parameters on OpenClaw 5.7 but not on 4.14/4.24 — no local workaround exists

Environment

• OpenClaw: 2026.5.7 (eeef486) — macOS arm64, npm global install
• OS: macOS 26.4.1 (Apple Silicon M3)
• Model: GPT-5.5 via custom provider (api: openai-completions, proxied through ai-service.tal.com)
• Comparison instance: OpenClaw 4.14 → 4.24 on a second machine, same model, same API endpoint, same key

What happened

Starting around 2026-05-19, every exec tool call from GPT-5.5 on our 5.7 gateway includes ask: "on-miss" and security: "allowlist" in the tool call arguments. Because requiresExecApproval checks ask === "on-miss" && security === "allowlist" && !allowlistSatisfied, this triggers an approval prompt for every command not in the durable allowlist — including trivial commands like ls /tmp, echo hello, date.

The same model (GPT-5.5), same API endpoint, same API key, same tool schema, running on a second machine with OpenClaw 4.24 does not exhibit this behavior. On 4.24, GPT-5.5 passes ask: null, security: null (or omits them entirely) and commands execute normally.

Impact

• Complete loss of exec usability for GPT-5 agents on 5.7. Every command requires manual /approve.
• No local workaround exists (see exhaustive list below).
• The agent is effectively unusable for any workflow involving shell commands.

Root cause analysis

The minSecurity/maxAsk merge logic in exec-approvals-effective takes the stricter of model-supplied params vs config:

• minSecurity(model="allowlist", config="full") → allowlist (model wins)
• maxAsk(model="on-miss", config="off") → on-miss (model wins)

This means the model can only escalate security, never relax it. Once GPT decides to pass these params, no amount of config/policy change can override them.

Verified: code/schema identical between versions

We verified via md5 checksums and line-by-line comparison:

• bash-tools.schemas (exec tool schema): identical between 4.14/4.24 and 5.7
• exec-approvals-effective (approval logic): identical md5 hash
• requiresExecApproval function: identical implementation
• System prompt template (system-prompt-*.js): same approval-related instructions exist in both versions
• Tool definition sent to model (context.compiled.tools): identical exec tool JSON schema with same Optional ask/security parameters

What we tried (all failed on 5.7)

Expected behavior

Model-supplied ask and security parameters in exec tool calls should be ignored (or stripped) by the gateway before the approval decision is made. The configured policy (tools.exec.* + exec-approvals.json) should be the sole authority on approval behavior.

Alternatively, minSecurity/maxAsk should not allow model-supplied values to override operator-configured policy.

Suggested fix

Before calling requiresExecApproval, strip or ignore params.ask and params.security when they originate from the model's tool call arguments (as opposed to operator config). The tool schema exposes these as Optional parameters for legitimate operator/CLI use, but models should not be able to escalate security policy autonomously.

Additional context

• The exec tool schema has ask and security as Optional string parameters with descriptions like "Exec ask mode (off|on-miss|always)" — this effectively teaches the model valid values
• GPT-5 models appear to fill Optional parameters more aggressively than other model families
• On 4.14/4.24, the same schema is exposed but GPT passes null values — suggesting something in 5.7's request pipeline (transport layer, plugin hooks, or prompt construction) is different in a way we could not identify
• We attempted to capture the actual HTTP request payload via source instrumentation, but the transport path for our custom provider (api: openai-completions) was not the one we expected (createOpenAICompletionsTransportStreamFn was never called), suggesting a plugin hook or alternative routing
• Issue #84517 was previously filed and closed by ClawSweeper claiming 5.18 fixed it, but no changelog entry corroborates this, and 5.18/5.19 have a separate macOS crash-loop bug (#83968) preventing us from upgrading to verify