PR #16: fix(exec): honor user's tools.exec.security config setting

• Repository: Jimmy-xuzimo/openclaw
• Author: Jimmy-xuzimo
• State: closed | merged: False
• Link: https://github.com/Jimmy-xuzimo/openclaw/pull/16

Description (problem / solution / changelog)

This PR was created incorrectly. Please refer to the correct PR at: https://github.com/Jimmy-xuzimo/openclaw/pull/16

Changed files

• src/agents/bash-tools.exec-host-gateway.ts (modified, +2/-1)
• src/agents/bash-tools.exec.ts (modified, +2/-1)

---

PR #64401: fix(exec): honor user's tools.exec.security config setting

• Repository: openclaw/openclaw
• Author: Jimmy-xuzimo
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/64401

Description (problem / solution / changelog)

Thank you for the detailed review. You raise valid concerns.

To answer your question about ~/.openclaw/exec-approvals.json - I don't have access to the reporter's config file, as this issue was reported by someone else.

However, your analysis is compelling:

1. The safety invariant (host can always tighten, never broaden) should be preserved
2. If approvals.agent.security resolves to "deny", that's likely a misconfiguration rather than a code bug
3. My fix bypasses minSecurity entirely, which is too aggressive

I'll close this PR and investigate the actual root cause - which may be in how the default approval config is generated, or the reporter may have a stale exec-approvals.json file.

Thank you for the thorough review.

Changed files

• src/agents/bash-tools.exec-host-shared.ts (modified, +5/-1)

---

PR #64626: fix(exec): honor user's explicit "full" when approvals default matches

• Repository: openclaw/openclaw
• Author: Jimmy-xuzimo
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/64626

Description (problem / solution / changelog)

Thank you for the detailed review.

After careful consideration, I agree with the P1 comment - my fix is too aggressive. If a host administrator explicitly sets defaults.security: "deny" to enforce a restrictive policy, my fix would incorrectly bypass that.

The issue is that if a user's exec-approvals.json has stale/incorrect defaults, that's a configuration problem, not a code bug. The minSecurity() function exists precisely to ensure host-wide policies are respected.

I should not have bypassed minSecurity() when the source is defaults.security, because defaults.security can be an explicit restrictive policy set by the host admin, not just an accidental fallback.

I'll close this PR. The real fix for users experiencing this issue is to:

1. Run openclaw doctor to inspect the effective policy
2. Fix any stale/incorrect values in ~/.openclaw/exec-approvals.json

Thank you for the thorough review - this was a valuable learning experience about the importance of preserving security invariants.

Changed files

• src/agents/bash-tools.exec-host-shared.ts (modified, +13/-3)

---

PR #2: security(exec): attribute 'exec denied' to its config source (#64361)

• Repository: Rugangsystem/openclaw-bytedance
• Author: ymaxgit
• State: open | merged: False
• Link: https://github.com/Rugangsystem/openclaw-bytedance/pull/2

Description (problem / solution / changelog)

Summary

• Problem: when the exec tool is denied, the thrown error exec denied: host=<h> security=deny tells the operator nothing about which file or key actually caused the deny. Reporter in openclaw/openclaw#64361 had tools.exec.security: "full" in openclaw.json but still got blocked because their `~/.openclaw/exec-approvals.json` resolved to `security=deny`, and the error gave no way to find that out without reading the source.
• Why it matters: `exec-approvals.json` is intentionally authoritative — `openclaw.json:tools.exec.security` can only tighten it, never loosen it (the comment at `src/agents/bash-tools.exec-host-shared.ts:202-203` calls this out explicitly). The security design is correct; the diagnostic is the gap.
• What changed: extract the deny-error construction into `buildExecDeniedMessage(...)` and include which source resolved to deny (using the already-populated `approvals.agentSources.security`) plus whether the caller's requested `tools.exec.security` was looser, in which case the message explains that it cannot loosen the host-file setting.
• What did NOT change (scope boundary): no change to the deny decision itself. `minSecurity(params.security, approvals.agent.security)` still wins; the host-file still wins on deny. The stable `exec denied: host=<h> security=deny` prefix is preserved so existing log/alert matchers keep working.

Closes #64361.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #64361
• Related #
• This PR fixes a bug or regression

Root Cause

• Root cause: `resolveExecHostApprovalContext` correctly computes `hostSecurity = minSecurity(caller, hostFile)` and throws when the intersection is `deny`, but the thrown `Error` carries only the host string — no source attribution. The attribution data (`approvals.agentSources.security`) is already computed by `resolveExecApprovals` for exactly this purpose (it was added for the exec-policy CLI), so plumbing it into the error is a pure diagnostic improvement.
• Missing detection / guardrail: no test was asserting that the deny error tells operators why. Added three.
• Contributing context: reporter in #64361 spent real debugging time (rebooting, hot-reload, killing processes) on what turned out to be a two-config-source problem the error message didn't surface.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: `src/agents/bash-tools.exec-host-shared.test.ts` — added regression tests in the existing `resolveExecHostApprovalContext` describe and a new `buildExecDeniedMessage` describe.
• Scenario the test should lock in:
  • exec-approvals.json security=deny + config tools.exec.security=full → error names the exec-approvals source and explains config cannot loosen
  • agentSources missing (older callers) → fallback attribution still names exec-approvals.json
  • exec-approvals.json relaxed + caller requested deny → attribution swings to the config side
• Why this is the smallest reliable guardrail: these three cases exercise both attribution branches and the fallback, matching the decision table in `buildExecDeniedMessage`.
• Existing test that already covers this: none — the pre-existing tests only assert the numeric outcome (hostSecurity / hostAsk / askFallback), not the error text.
• If no new test is added: N/A, tests added.

User-visible / Behavior Changes

• Error text change: `exec denied: host=gateway security=deny` now looks like `exec denied: host=gateway security=deny — exec-approvals.json security=deny (agents.default.security); openclaw.json tools.exec.security=full cannot loosen this`.
• The prefix `exec denied: host=<h> security=deny` is preserved. Anything that keyed on the exact previous full string will need to either match the prefix or accept a trailing diagnostic clause.

Diagram

```text Before: [exec call] -> [resolver: min(config, host-file)=deny] -> [throw "exec denied: host=gateway security=deny"] -> [operator has no idea which file]

After: [exec call] -> [resolver: min(config, host-file)=deny] -> [throw "exec denied: host=gateway security=deny — <attribution>"] -> [operator fixes the right file] ```

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? Diagnostic only — the deny decision is unchanged. No code path now allows exec that didn't allow it before.
• Data access scope changed? No
• If any `Yes`, explain risk + mitigation: N/A

The new error text includes the exec-approvals source key (e.g. `agents.default.security`) and the configured `tools.exec.security` value. Neither is a secret. No paths, hostnames, or user-supplied strings are echoed.

Repro + Verification

Environment

• OS: macOS (Darwin)
• Runtime/container: local Node 22 via pnpm 10
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): `openclaw.json:tools.exec.security="full"` + a default-seeded `~/.openclaw/exec-approvals.json` with `security="deny"`

Steps

1. Set `tools.exec.security: "full"` in openclaw.json
2. Have `~/.openclaw/exec-approvals.json` resolve `agent.security` to `"deny"` (e.g. default-seeded)
3. Trigger an exec via the gateway
4. Before this PR, the error said `exec denied: host=gateway security=deny` and stopped there.

Expected

``` exec denied: host=gateway security=deny — exec-approvals.json security=deny (agents.default.security); openclaw.json tools.exec.security=full cannot loosen this ```

Actual

Matches Expected after this PR. Verified via the three new unit tests.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

``` $ pnpm test src/agents/bash-tools.exec-host-shared.test.ts Test Files 1 passed (1) Tests 16 passed (16)

$ pnpm check Import cycle check: 0 Madge import cycle check: 0 tsgo: clean oxlint: 0 warnings, 0 errors ```

Human Verification

• Verified scenarios:
  • reporter's scenario (openclaw.json says full, exec-approvals.json says deny) — error now names the source
  • opposite direction (openclaw.json says deny, exec-approvals.json relaxed) — attribution swings to the config
  • agentSources missing on the resolver result — attribution falls back cleanly
  • stable prefix preserved
• Edge cases checked:
  • no `agentSources` field present → no `(...)` parenthetical, but the main clause is still emitted
  • `requestedSecurity === "deny"` path → "openclaw.json tools.exec.security=deny" branch
• What I did not verify:
  • live gateway restart path with a real exec-approvals.json on disk — the fix is mechanical and fully covered by unit tests against the existing resolver contract, so a live repro wasn't necessary to validate the change.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — the error's stable prefix is preserved; the trailing diagnostic is additive.
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: consumers that match the exact old error string fail.
  • Mitigation: the `exec denied: host=<h> security=deny` prefix is preserved and is what existing log matchers in the tree key on. I grepped for the old exact string and the hits are all either this file itself or docs/CHANGELOG.
• Risk: the attribution could leak a user-defined agent id via `agents.<agentKey>.security`.
  • Mitigation: agent ids are config-provided identifiers already visible in `openclaw status` and logs; they aren't secret. The source string is a path-like key into the user's own `exec-approvals.json`, not any value.

Changed files

• src/agents/bash-tools.exec-host-shared.test.ts (modified, +125/-1)
• src/agents/bash-tools.exec-host-shared.ts (modified, +48/-1)