PR #60842: fix(agents): re-expose toolsAllow core tools in embedded runs

• Repository: openclaw/openclaw
• Author: ricoyudog
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60842

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: embedded runs only post-filtered toolsAllow after createOpenClawCodingTools, so restrictive config allowlists could remove exec/read/write before toolsAllow had any effect.
• Why it matters: cron/isolated runs with toolsAllow: ["exec"] still lost exec under configs like tools.allow: ["group:openclaw"], breaking workflows that depended on explicit per-run tool exposure.
• What changed: runEmbeddedAttempt now forwards toolsAllow into createOpenClawCodingTools, and the tool policy merge re-exposes explicitly requested core tools through restrictive config allowlists without overriding deny.
• What did NOT change (scope boundary): this does not bypass explicit deny, sandbox/group/subagent tool policies, or provider/runtime capability gating.

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 #60841
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: runEmbeddedAttempt only did a final .filter() against toolsAllow, but createOpenClawCodingTools had already applied config-driven allowlists. Once the policy pipeline filtered a core tool out, the later post-filter could not re-add it.
• Missing detection / guardrail: there was no regression test covering toolsAllow under a restrictive config allowlist such as group:openclaw.
• Contributing context (if known): group:openclaw intentionally excludes exec, process, read, write, and edit, so the bug is deterministic under configs that rely on that group and then expect toolsAllow to re-expose a core tool for a specific run.

Regression Test Plan (if applicable)

• 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/pi-tools-agent-config.test.ts, src/agents/pi-embedded-runner/run/attempt.memory-flush-forwarding.test.ts
• Scenario the test should lock in: restrictive config allowlists still permit explicitly requested core tools for that embedded run, while explicit deny continues to win.
• Why this is the smallest reliable guardrail: one test pins the effective tool inventory after policy application, and the other pins the runEmbeddedAttempt -> createOpenClawCodingTools forwarding seam.
• Existing test that already covers this (if any): None.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Embedded runs that set toolsAllow can now re-expose the requested core tools (exec, read, write, etc.) even when a restrictive config allowlist would otherwise hide them. Explicit deny still wins.

Diagram (if applicable)

Before:
[embedded run with toolsAllow=[exec]] -> [createOpenClawCodingTools applies config allowlist] -> [exec removed] -> [post-filter keeps missing set] -> [cron run still has no exec]

After:
[embedded run with toolsAllow=[exec]] -> [forceAllowTools merged into restrictive config allowlists] -> [exec survives policy pipeline unless denied] -> [post-filter selects exec] -> [cron run gets exec]

Security Impact (required)

• New permissions/capabilities? Yes
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? Yes
• Data access scope changed? Yes
• If any Yes, explain risk + mitigation: The PR allows an embedded run to re-expose explicitly requested core tools through restrictive config allowlists. Mitigation: the re-exposure is limited to named core tools for that run, explicit deny still wins, and sandbox/group/subagent/provider/runtime restrictions still apply.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local source checkout
• Model/provider: policy regression is model-agnostic; forwarding seam verified with openai/gpt-5.4
• Integration/channel (if any): embedded runner / cron-style tool exposure
• Relevant config (redacted): tools.profile: "full", tools.allow: ["group:openclaw"]

Steps

1. Configure a restrictive core-tool allowlist such as tools.allow: ["group:openclaw"].
2. Run an embedded attempt with toolsAllow: ["exec"].
3. Inspect the effective tool set.

Expected

• The effective tool set contains exec for that run unless a stronger deny/runtime restriction blocks it.

Actual

• Before this fix, exec was missing because it had already been filtered out before toolsAllow was applied.

Evidence

Attach at least one:

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

Human Verification (required)

• Verified scenarios: targeted regression tests for restrictive allowlist re-exposure and explicit-deny precedence; full attempt.memory-flush-forwarding test file; pnpm check; pnpm build.
• Edge cases checked: allow-all semantics are preserved, explicit deny still blocks forced tools, and only known core tool ids are re-exposed.
• What you did not verify: I did not run a live end-to-end cron job against a local gateway build from this branch.

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
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: a per-run toolsAllow request could unintentionally widen a restrictive config allowlist too broadly.
  • Mitigation: the merge only applies to explicitly requested known core tools, and allow-all / deny semantics are preserved.

Changed files

• src/agents/pi-embedded-runner/run/attempt.memory-flush-forwarding.test.ts (modified, +39/-0)
• src/agents/pi-embedded-runner/run/attempt.ts (modified, +1/-0)
• src/agents/pi-tools-agent-config.test.ts (modified, +38/-1)
• src/agents/pi-tools.ts (modified, +43/-16)
• src/agents/tool-policy.ts (modified, +13/-0)