openclaw - 💡(How to fix) Fix lightContext:true + toolsAllow:['exec'] on main agent — exec tool not registered in session, agent silently reports no-exec

Summary

In OpenClaw 2026.5.19, when a cron payload sets both lightContext: true AND toolsAllow: ['exec'] on the main agent, the resulting isolated session does NOT have the exec tool registered. The agent then reports a graceful failure ("this session does not expose a shell/exec tool, so the command could not be executed"), the cron framework records the run as status: ok (because the agent terminated cleanly), and any announce delivery sends the failure message as if it were the routine's intended output.

Setting lightContext: false on the same cron immediately resolves the problem and the exec tool becomes available — confirmed end-to-end on the same install with no other changes.

Repro

{
  "agentId": "main",
  "payload": {
    "kind": "agentTurn",
    "lightContext": true,
    "toolsAllow": ["exec"],
    "message": "Use the exec tool to run `/bin/echo hello`."
  }
}

Expected: agent runs the exec call, returns "hello".

Observed: agent returns "this session does not expose a shell/exec tool, so the command could not be executed". Cron status is ok. Announce-delivered text is the failure.

Switching to lightContext: false (and not changing anything else) makes the same cron complete successfully — exec is registered, agent runs the command, real output is announced.

Likely cause

The lightContext: true path strips tools beyond the minimal bootstrap set. Whatever defines "what's in the light set" appears to have changed between 2026.5.7 and 2026.5.19 — quite possibly via the new @openclaw/codex provider plugin (introduced ~2026.5.12, became default OAuth provider in 5.19) or the lossless-claw plugin (introduced 2026.5.19). The cron payload's toolsAllow is intended to grant tools, but in this regression it appears it can only filter from what's already been loaded into the session's tool registry. With lightContext on, exec isn't registered → toolsAllow: ['exec'] becomes effectively empty → the agent sees no exec.

Why this is a real bug, not a config gotcha

1. The combination is documented as supported. The lightContext flag is meant to reduce bootstrap context cost without affecting tool availability. toolsAllow is meant to whitelist tools for that session. Both flags being set should imply "load only these tools, in light context mode."
2. No warning is emitted. The agent doesn't surface "you asked for exec but I don't have it" anywhere visible to the cron framework or the user — the cron sees status: ok, the announce-delivery sends an ambiguous failure message, and only an operator manually reading the session jsonl can identify what went wrong.
3. The failure is silent for announce deliveries. Because the agent generates a final response (just not the intended one), the announce path treats it as a normal completion. Users see "Daily scan failed: no exec tool" delivered to WhatsApp/Slack/Telegram as if it were the scan's verdict.

Multi-cron impact on this install

After diagnosing the issue, an audit of all 30 OpenClaw crons on this install found 8 with the lightContext: true + toolsAllow: ['exec'] combination, including reliability-critical ones:

• Memory Promotion Quality Filter (03:15 BST daily)
• Session Size Monitor (04:30 BST daily)
• Memory Reindex — Midday (12:00 BST daily)
• Paperclip Task Audit (18:00 BST daily)
• Daily Transaction Processor — OpenClaw WhatsApp Orchestrator (20:00 BST daily)
• • 3 others

These all worked correctly under earlier OpenClaw versions. They have all been workaround-patched to lightContext: false on this install pending an upstream fix.

Suggested fix

Two options:

1. Make toolsAllow additive over the lightContext base set. If a cron payload's toolsAllow references a tool not in the lightContext default registry, load that tool into the session's tool registry on top of the light set. That's the principle-of-least-surprise behaviour.

2. At minimum, emit a clear warning when toolsAllow references unregistered tools. Something like: [cron] payload.toolsAllow includes ["exec"] but lightContext=true does not register this tool — agent will not have exec available. Set lightContext=false to use exec from cron sessions. This makes the bug obvious instead of silent.

Option 1 is the right behaviour. Option 2 catches the operator-error case where someone has both flags set without realising the interaction.

Environment

• OpenClaw 2026.5.19 (regression appeared between 2026.5.7 and 2026.5.19 — narrower bisection not done)
• Affected agent: main (OpenClaw front-door, claude_local adapter not involved here — this is OpenClaw-side tool registration)
• macOS, LaunchAgent-managed gateway

Related

• Prior upstream filings from this install: paperclipai/paperclip#5561, openclaw/openclaw#77458, openclaw/openclaw#82358
• Pair-bug from the same install: separately-filed openclaw update silently reverts user-customised config blocks.