Summary

Scheduled cron agentTurn runs do pass toolsAllow, but the allowlist is only applied to the base OpenClaw tool registry. Bundled MCP/LSP tools are materialized later and appended after policy filtering without reapplying toolsAllow, which allows an exec-only cron to compile with exec + 45 Atlassian tools in scheduled runs.

In our current fleet this is wasting roughly ~370k input tokens/day on average across live allowlisted cron jobs.

Impact

Current observed fleet impact:

• 11 enabled allowlisted agentTurn cron jobs
• estimated waste: ~2.58M extra input tokens/week
• estimated average: ~368k/day
• confirmed floor from just two observed leaking jobs: ~326k/day

This is a real cost/perf bug, not just a weird Work Inbox Review anecdote.

Expected behavior

If a cron payload sets:

"toolsAllow": ["exec"]

then the compiled context should only serialize exec (plus any other explicitly allowed tools), regardless of whether bundled MCP/LSP tools are available in the runtime.

Actual behavior

For scheduled cron agentTurn runs:

• toolsAllow is passed into the embedded attempt path
• the base tool registry is filtered correctly
• bundled MCP/LSP tools are materialized later
• those bundled tools are appended to the final effective tool list without reapplying toolsAllow

Result: scheduled exec-only runs can still serialize exec + 45 Atlassian MCP tools.

Repro evidence

A. Manual validation run (correct behavior)

Trajectory session: f36ec82e-ada6-4dea-9906-b8e25d7d852c

Runtime config:

{
  "timeoutMs": 120000,
  "trigger": "cron",
  "disableTools": false,
  "toolResultFormat": "markdown",
  "toolsAllow": ["exec"]
}

Observed:

• compiled tools: ['exec']
• tool schema chars: 1155
• system prompt chars: 40239

B. Scheduled cron run (buggy behavior)

Trajectory session: 5d1beac3-1b5e-4881-a6a1-6d23561df888

Same runtime config:

{
  "timeoutMs": 120000,
  "trigger": "cron",
  "disableTools": false,
  "toolResultFormat": "markdown",
  "toolsAllow": ["exec"]
}

Observed:

• compiled tools: exec + 45 Atlassian MCP tools
• tool schema chars: 45116
• system prompt chars: 42227

C. Second confirmed leaking allowlisted cron

Trajectory session: 6d8a7260-4351-45a2-ab78-76e891df200e

Observed:

• same leak shape: exec + 45 Atlassian MCP tools
• tool schema chars: 45116
• system prompt chars: 42230

D. Control: scheduled cron without toolsAllow

Trajectory session: e39c58d1-7fc1-416c-a112-72559e5f6182 (Daily Zight Review)

Observed:

• no toolsAllow
• compiled tool count: 20
• tool schema chars: 16169
• system prompt chars: 50582

This suggests the bug is not “all scheduled agentTurn runs load 46 tools.” It affects runs where toolsAllow narrows the base registry, but bundled tools are appended afterward.

Traced call path

dist/index.js is just the launcher. The scheduled cron path resolves to:

• dist/index.js
• server.impl-D40kmTX8.js:3173 calls executeCronRun(...)
• run-executor.runtime-r9xOO-zi.js:102-138 calls runEmbeddedPiAgent(...) with toolsAllow: params.agentPayload?.toolsAllow
• pi-embedded-runner-BFOhIiuh.js:28/883/1297
• selection-DGLE6AvW.js

context.compiled is recorded at:

• selection-DGLE6AvW.js:6925

Relevant tool assembly lines:

• selection-DGLE6AvW.js:5693 — applyEmbeddedAttemptToolsAllow(tools, toolsAllow)
• selection-DGLE6AvW.js:5749 — base registry filtered via applyEmbeddedAttemptToolsAllow(createOpenClawCodingTools(...), params.toolsAllow)
• selection-DGLE6AvW.js:5900 — materializeBundleMcpToolsForRun(...)
• selection-DGLE6AvW.js:5913 — applyFinalEffectiveToolPolicy(...)
• selection-DGLE6AvW.js:5934 — const effectiveTools = [...tools, ...filteredBundledTools];

Root cause

toolsAllow is being read at the right point for the base OpenClaw tool registry, but too early in the overall pipeline.

The bundled MCP/LSP tools are created later and appended into effectiveTools without any second allowlist pass.

So this is not:

• “the scheduler ignores toolsAllow entirely”
• nor “all 46 tools are built first and never filtered”

It is:

• base tools filtered correctly
• bundled tools appended later without allowlist filtering

Suggested fix

Minimal patch:

• reapply toolsAllow after bundled MCP/LSP tool materialization, before finalizing effectiveTools

Likely safest places:

1. filter filteredBundledTools by the same allowlist set before appending, or
2. apply the allowlist again to the final effectiveTools

Conceptually:

const allowSet = new Set(params.toolsAllow ?? [])
const effectiveTools = params.toolsAllow?.length
  ? [...tools, ...filteredBundledTools].filter(tool => allowSet.has(tool.name))
  : [...tools, ...filteredBundledTools]

Why this matters

This bug silently increases prompt size, latency, and cost for thin scheduled cron jobs that are explicitly configured to use a tiny toolset.

The operator thinks they have an exec-only cron, but the scheduled run can still serialize a large bundled MCP catalog into context.compiled.