openclaw - 💡(How to fix) Fix [Bug]: 2026.5.18 isolated cron agent turns omit requested exec tool despite toolsAllow [2 comments, 3 participants]

Bug type

Regression (worked before, now fails)

Summary

After upgrading to OpenClaw 2026.5.18, isolated OpenClaw cron agent turns intermittently start without the requested exec tool, even when the cron payload explicitly sets toolsAllow to include exec. The jobs then fail before running their command, often reporting that only sessions_send was exposed.

This regressed scheduled jobs that are command wrappers / watchdogs. The same scripts run successfully under user systemd timers, so the scripts and host permissions are not the failing layer.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• Install: npm global
• OS: Linux x64, gateway via systemd user service
• Runtime: OpenAI Codex / openai/gpt-5.5
• Affected path: OpenClaw cron jobs using payload.kind: "agentTurn", sessionTarget: "isolated", agentId: "c3po"

Affected jobs observed locally

The following OpenClaw cron jobs were moved temporarily to user systemd timers so they would not silently miss runs:

• OpenClaw update check (f3e836c7-6038-439c-b98d-3a0db3d35178)
  • Schedule: daily 2:00 AM America/New_York
  • Required tool: exec
  • Moved to: openclaw-update-check.timer
• gateway-memory-watch (b9779563-5e07-417f-870d-5e756fd8ff2a)
  • Schedule: every 15 minutes
  • Required tools: exec, sessions_send
  • Moved to: gateway-memory-watch.timer
• Vault inbox processor (91c17edf-f6ac-475e-a912-db6e9118004f)
  • Schedule: every 5 minutes
  • Required tools: exec, sessions_send
  • Moved to: vault-inbox-processor.timer

Once this cron tool-hydration issue is fixed, we want to move these back into OpenClaw cron. We prefer keeping them in OpenClaw rather than systemd.

Job configuration proof

The cron job definitions request exec explicitly:

{
  "id": "f3e836c7-6038-439c-b98d-3a0db3d35178",
  "name": "OpenClaw update check",
  "agentId": "c3po",
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "toolsAllow": ["exec"],
    "timeoutSeconds": 120
  }
}

{
  "id": "91c17edf-f6ac-475e-a912-db6e9118004f",
  "name": "Vault inbox processor",
  "agentId": "c3po",
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "toolsAllow": ["exec", "sessions_send"],
    "thinking": "off",
    "lightContext": true,
    "timeoutSeconds": 120
  }
}

{
  "id": "b9779563-5e07-417f-870d-5e756fd8ff2a",
  "name": "gateway-memory-watch",
  "agentId": "c3po",
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "toolsAllow": ["exec", "sessions_send"],
    "thinking": "off",
    "lightContext": true,
    "timeoutSeconds": 120
  }
}

Observed failures

Examples from run/session history on 2026-05-19:

[blocked] exec tool is not available in this session, so I could not run the requested command.

[blocked] The requested exec tool is not available in this turn; only sessions_send was exposed after tool discovery, so I could not run /home/clawdbot/clawd/scripts/vault-inbox-processor.sh.

[blocked] Cron command could not be run because the required exec tool is not available in this session; only sessions_send was exposed.

For the update check specifically:

{
  "id": "f3e836c7-6038-439c-b98d-3a0db3d35178",
  "status": "error",
  "summary": "[blocked] exec tool is not available in this session, so I could not run the requested command.",
  "error": "cron classifier: denial token \"could not run\" detected in summary"
}

For gateway-memory-watch and Vault inbox processor, repeated runs failed the same way. Some later runs were marked ok despite the assistant text still saying the command did not run, which makes this more dangerous: the scheduler can appear healthy while the intended shell command was skipped.

Expected behavior

If a cron job payload includes:

"toolsAllow": ["exec"]

or:

"toolsAllow": ["exec", "sessions_send"]

then the isolated cron agent turn should receive the exec tool, or the cron run should fail loudly at preflight with a tool-hydration/runtime configuration error.

Actual behavior

The isolated cron turn sometimes receives only sessions_send or otherwise lacks exec, then the model returns a blocked summary instead of executing the command.

The important distinction: toolsAllow appears to be acting as a filter over whatever tools were already hydrated, not as a guarantee that required tools are made available to the cron run.

Why this looks like a 2026.5.18 regression

These jobs were already configured as command-based cron/watchdog jobs. After the 2026.5.18 update, multiple independent cron jobs with explicit toolsAllow started failing with the same missing-exec symptom.

The underlying scripts succeed when run directly under user systemd services/timers:

• openclaw-update-check.service
• gateway-memory-watch.service
• vault-inbox-processor.service

That isolates the problem to the OpenClaw cron isolated-agent runtime/tool exposure path, not the commands themselves.

Impact

• Scheduled maintenance / watchdog jobs silently miss their intended command execution.
• Some failures are delivered to Telegram, but some runs can be marked ok despite not running the command.
• Operators may move jobs out of OpenClaw cron into systemd as a workaround, losing the integrated OpenClaw scheduling UX.

Related issues checked

I searched open issues for cron + exec/tool exposure/session_send before filing. Related but not duplicates:

• #61095: agent exec inherits gateway internal env vars and CLI commands fail. Different failure: exec exists but command fails.
• #75811: model-controllable exec.security/approval fields causing self-denial. Different failure: exec exists but arguments can self-deny.
• #49876: cron sessions hallucinate output instead of failing cleanly when tool calls fail. Adjacent symptom, but not the missing-tool hydration regression.
• #79329: cron model preflight ignores fallbacks. Different cron preflight path.

Suggested fix direction

• Add a preflight validation step for cron jobs: if payload.toolsAllow includes exec, verify exec is actually present in the hydrated runtime tool set before model invocation.
• Treat missing required tools as a scheduler/runtime failure, not as a normal model turn.
• Ensure toolsAllow for cron jobs is applied after the full normal tool set for that agent/session has been hydrated, not before or against a reduced messaging-only set.