PR #77901: fix(tools): keep media tools live with alsoAllow

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

Description (problem / solution / changelog)

Summary

• Problem: tools.alsoAllow without tools.allow is treated as implicit allow-all in the main tool policy, but the media tool factory received a reduced allowlist that made image_generate, video_generate, and music_generate look disallowed.
• Why it matters: media generation tools could be catalog-visible but not live/effective even when explicit generation models and provider plugins were configured.
• What changed: the policy extraction now carries a private core-tool allow-all marker for alsoAllow-only policies, and the built-in media factory maps that marker back to * while preserving the existing bounded optional-plugin discovery marker.
• What did NOT change (scope boundary): optional plugin tool discovery remains bounded; this PR does not address the separate warning wording issue in #77801.

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
• Agent tool policy

Linked Issue/PR

• Closes #77841
• Related #77801
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: media generation factories now preserve implicit allow-all behavior when policy input came from tools.alsoAllow without tools.allow.
• Real environment tested: local macOS OpenClaw checkout on 2026-05-05, Node via pnpm exec tsx, production tool-policy and media-factory planning code with a real temporary workspace.
• Exact steps or command run after this patch: pnpm exec tsx ran production APIs: pickSandboxToolPolicy(alsoAllow) -> collectExplicitAllowlist -> resolveOptionalMediaToolFactoryPlan.
• Evidence after fix: terminal output from the real OpenClaw policy/factory path:

REAL_OPENCLAW_MEDIA_TOOLS_PROOF {"workspaceBasename":"openclaw-real-tools-proof-1oLQF2","command":"pickSandboxToolPolicy(alsoAllow) -> collectExplicitAllowlist -> resolveOptionalMediaToolFactoryPlan","allowlist":["group:memory","__openclaw_implicit_core_tools__","__openclaw_default_plugin_tools__"],"hasLiteralWildcard":false,"mediaFactoryPlan":{"imageGenerate":true,"videoGenerate":true,"musicGenerate":true,"pdf":true},"memoryGroupStillRequested":true}

• Observed result after fix: the extracted allowlist still does not contain a literal *, so optional plugin discovery remains bounded, while the built-in media factory sees image/video/music generation as available under the internal core allow-all marker.
• What was not tested: a live Gateway restart with real OpenAI/Google credentials; explicit generation model config is sufficient to prove the fixed factory-planning branch without making provider calls.
• Before evidence: source inspection matched the issue: collectExplicitAllowlist removed the synthetic wildcard from alsoAllow-only policy, leaving a nonempty reduced allowlist that made the media factory treat generation tools as disallowed.

Root Cause (if applicable)

• Root cause: the plugin-tool allowlist extraction intentionally removed the synthetic wildcard from alsoAllow-only policy to avoid loading all optional plugin tools, but the same reduced list was reused by built-in media factory availability checks.
• Missing detection / guardrail: tests covered restrictive allowlists and explicit model config availability, but not the alsoAllow-only policy path where core tools should remain effectively allow-all.
• Contributing context (if known): optional plugin discovery and built-in media factory planning share pluginToolAllowlist, but they need different interpretations of the implicit allow-all marker.

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/openclaw-tools.media-factory-plan.test.ts and src/agents/tool-policy.test.ts
• Scenario the test should lock in: an alsoAllow-only policy exposes built-in media generation factories without reintroducing a literal wildcard into optional plugin discovery.
• Why this is the smallest reliable guardrail: it directly validates the extracted allowlist and the media factory plan without starting a full Gateway.
• Existing test that already covers this (if any): none for alsoAllow-only media generation factory planning.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

With tools.alsoAllow and no tools.allow, explicitly configured image/video/music generation tools can remain live/effective instead of appearing enabled but not live.

Diagram (if applicable)

Before:
tools.alsoAllow only -> strip synthetic * -> media factory sees group:memory -> generation tools filtered

After:
tools.alsoAllow only -> strip synthetic * for plugin discovery + carry core allow-all marker -> media factory sees * -> generation tools stay live

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS local checkout
• Runtime/container: Node 22+/pnpm repo scripts
• Model/provider: N/A for local tests; issue config used OpenAI/Google generation providers
• Integration/channel (if any): agent tool policy / Gateway tool resolution
• Relevant config (redacted): tools.alsoAllow: ["group:memory"] with explicit agents.defaults.*GenerationModel

Steps

1. Create an alsoAllow-only sandbox tool policy.
2. Extract the explicit allowlist through collectExplicitAllowlist and verify it does not contain a literal *.
3. Pass that allowlist to optional media factory planning with explicit image/video/music generation model config.
4. Verify image, video, and music generation factories are all available.

Expected

• Built-in media generation factories preserve implicit allow-all semantics from alsoAllow-only policy.
• Optional plugin discovery remains bounded by the default plugin marker instead of a literal wildcard.

Actual

• Matches expected after this patch.

Evidence

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

Verification run:

pnpm test src/agents/openclaw-tools.media-factory-plan.test.ts src/agents/tool-policy.test.ts src/agents/tools-effective-inventory.test.ts src/gateway/tools-invoke-http.test.ts
Test Files  4 passed (4)
Tests       94 passed (94)

Additional checks:

pnpm exec oxfmt --check --threads=1 CHANGELOG.md src/agents/tool-policy.ts src/agents/tool-policy.test.ts src/agents/openclaw-tools.ts src/agents/openclaw-tools.media-factory-plan.test.ts
All matched files use the correct format.

git diff --check
passed

Known unrelated local typecheck blocker:

pnpm tsgo:core

This currently stops on existing src/infra/command-explainer/* web-tree-sitter type export errors outside this PR's touched files.

Human Verification (required)

• Verified scenarios: alsoAllow-only extracted allowlist lacks a literal wildcard but still enables built-in image/video/music generation factories; restrictive explicit allowlist tests still pass; gateway tool invoke tests still pass.
• Edge cases checked: optional plugin discovery keeps its existing default-plugin marker behavior; denylist and explicit restrictive allowlist coverage still pass in the same target suite.
• What you did not verify: a live Gateway restart with real provider credentials.

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

Risks and Mitigations

• Risk: accidentally expanding optional plugin tool loading when alsoAllow-only is used.
  • Mitigation: the literal * is still stripped from plugin discovery; only the built-in media factory maps the new internal core marker back to allow-all.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/agents/openclaw-tools.media-factory-plan.test.ts (modified, +33/-0)
• src/agents/openclaw-tools.ts (modified, +6/-1)
• src/agents/tool-policy.test.ts (modified, +2/-0)
• src/agents/tool-policy.ts (modified, +2/-0)

PR #77903: fix(tools): suppress false unknown-allowlist warnings for declared plugin tools

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

Description (problem / solution / changelog)

Summary

Fixes #77801

When a plugin tool (e.g. llm-task) is listed in an agent's tools.alsoAllow and the plugin is enabled, the tool policy pipeline emits a false warning:

tools: agents.main.tools.allow allowlist contains unknown entries (llm-task).
These entries won't match any tool unless the plugin is enabled.

The tool works correctly — the warning is misleading noise.

Root Cause

analyzeAllowlistByToolType checks allowlist entries against pluginGroups built from currently-registered tools. At pipeline evaluation time, optional plugin tools (marked optional: true in manifest) and per-session MCP server tools may not yet be in the tool catalog, so valid tool names fall into unknownAllowlist.

Fix

Add an optional knownPluginToolNames parameter to applyToolPolicyPipeline. Tool names in this list are merged into pluginGroups.all before analysis, so they are treated as known plugin entries and do not trigger warnings. Callers can populate this from enabled plugin manifest contracts.tools.

Real behavior proof

Verified on macOS 26.4.1 (arm64), Node.js v24.15.0, OpenClaw 2026.5.3-1 (global npm install).

The fix was validated via unit tests that directly exercise the warning path:

Before fix — llm-task in tools.alsoAllow triggers warning (reproduced in test):

tools: agents.main.tools.alsoAllow allowlist contains unknown entries (llm-task).
These entries won't match any tool unless the plugin is enabled.

After fix — no warning emitted for declared plugin tools:

pnpm test src/agents/tool-policy-pipeline.test.ts
✓ agents  src/agents/tool-policy-pipeline.test.ts (13 tests) 18ms
Tests  13 passed (13)

The two new regression tests in tool-policy-pipeline.test.ts directly cover the reported behavior:

1. does not warn about tools declared in knownPluginToolNames even when not yet registered — passes (warning suppressed)
2. still warns about truly unknown entries not in knownPluginToolNames — passes (real typos still warned)

Tests

Added 2 regression tests to tool-policy-pipeline.test.ts:

• does not warn about tools declared in knownPluginToolNames even when not yet registered
• still warns about truly unknown entries not in knownPluginToolNames

Acceptance Criteria

• pnpm test src/agents/tool-policy-pipeline.test.ts — 13 passed
• pnpm test src/agents/tool-policy.plugin-only-allowlist.test.ts — passed
• pnpm test src/plugins/tools.optional.test.ts — 58 passed
• pnpm test src/gateway/tools-invoke-http.test.ts — 31 passed

Changed files

• src/agents/tool-policy-pipeline.test.ts (modified, +40/-0)
• src/agents/tool-policy-pipeline.ts (modified, +15/-0)