openclaw - 💡(How to fix) Fix [Bug]: 2026.4.29 silently drops exec/process from "messaging" tool profile, breaking isolated cron agent turns; cron run reports status: ok with error string as delivered output [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After updating from 2026.4.27 → 2026.4.29, every cron job whose isolated session resolves the messaging tool profile silently loses access to the exec and process tools mid-turn. The agent runs, the cron is "delivered" with status: "ok" from the scheduler, but the agent reports something like "this cron session doesn't have exec available" or "file not runnable" — and posts that error to its delivery target instead of the intended report.

OpenClaw prints this warning at startup:

tools policy: profile "messaging" (agent "main") has configured tool sections (tools.exec / tools.fs) that no longer implicitly widen the profile. Add alsoAllow: ["exec", "process"] explicitly if these tools should be available. See #47487.

…but the warning is stderr-only, the cron loop swallows it, and openclaw cron runs reports the run as status: ok (because it delivered something to the channel — the error string itself).

This is the same silent-regression failure mode I reported in #75753. The user has no signal that anything is wrong until they notice their cron's output is now an error message hours/days later.

Steps to reproduce

1. Configure ~/.openclaw/openclaw.json with:

   {
     "tools": {
       "profile": "messaging",
       "exec": {}
     }
   }

2. Create a cron whose payload is an agentTurn that needs to run a shell command. Example payload prompt: Run: python3 /path/to/some_script.py and post the output.
3. Schedule the cron in the past so it fires immediately, or wait for the next firing.
4. openclaw cron runs --id <jobId> shows status: "ok", delivered: true.
5. Inspect the delivered message: it's the agent reporting it could not call exec/process, e.g. "this cron session doesn't have exec available, so I couldn't read the Jira skill credentials or make API calls" or "ERROR: /path/to/script not found or not runnable" (the file does exist and is +x).

Expected behavior

Either:

1. The messaging profile retains its prior behavior of implicitly widening to include exec/process when those tool sections are configured (back-compat), OR
2. openclaw config validate and openclaw doctor fail loudly when a configured profile is missing tools the user's tool sections clearly expect (e.g., tools.exec is set but profile doesn't grant it), OR
3. Cron runs surface the warning to the user as a status: "warning" instead of swallowing it as status: "ok".

What I want is for the breakage to not be silent. The actual config edit (alsoAllow: ["exec", "process"]) is documented in the warning and trivial to make — but only if the user knows the warning exists.

Actual behavior

openclaw config validate returns Config valid. openclaw doctor does not flag it. Cron runs report status: "ok", delivered: true. The cron's delivered output is the agent saying it couldn't run a shell command — but this looks indistinguishable from a successful run unless someone manually reads the delivered messages.

OpenClaw version

2026.4.29 (regressed from 2026.4.27, which worked)

Operating system

macos (Darwin 25.3.0 arm64)

Install method

npm global

Model

Confirmed for github-copilot/gpt-4.1 and github-copilot/claude-sonnet-4.6 cron payloads. Likely affects every model running through an isolated cron session whose profile resolves to messaging (or any profile where the required tool sections aren't explicitly in alsoAllow).

Provider / routing chain

github-copilot → isolated cron session, agent: - (no specific agent), sessionTarget: isolated, wakeMode: now.

Additional provider/model setup details

• tools.profile: "messaging" (string form)
• tools.exec: {} (configured, but profile doesn't widen to grant it)
• Agent unspecified in the cron job (relies on default)

Logs, screenshots, and evidence

Two crons that broke today (2026-05-01) but ran fine on 2026-04-30:

RYAN_TO_DO Daily Report (github-copilot/claude-sonnet-4.6):

ts=1777563114530 status=error provider=-          err='FailoverError: fetch failed'                               (2026-04-30, deprecated /search endpoint — separate issue)
ts=1777647796345 status=ok    provider=github-copilot model=claude-sonnet-4.6
  summary: "Could not complete — this cron session doesn't have `exec` available,
            so I couldn't read the Jira skill credentials or make API calls."
  delivered: true

Product Review Auto-Runner (github-copilot/gpt-4.1):

ts=1777478692493 status=ok    provider=github-copilot model=gpt-4.1   (full report posted, 2026-04-29)
ts=1777564921328 status=ok    provider=github-copilot model=gpt-4.1   (full report posted, 2026-04-30)
ts=1777651226931 status=ok    provider=github-copilot model=gpt-4.1   (2026-05-01 — DELIVERS but content is the error)
  summary: "[Product Review Auto-Runner] ERROR: /Users/.../skills/viking-jira/scripts/product_review_report.py
            not found or not runnable. The path is missing, incorrect, or does not exist."

The script in question (product_review_report.py) exists at the configured path and is -rwx------ owner-executable. The file is reachable from a normal interactive session — python3 <path> runs it fine. Only the cron's isolated session can't reach it.

The startup warning naming this exact behavior:

tools policy: profile "messaging" (agent "main") has configured tool sections
(tools.exec / tools.fs) that no longer implicitly widen the profile.
Add alsoAllow: ["exec", "process"] explicitly if these tools should be available.
See #47487.

Impact and severity

Two crons broken silently overnight (Product Review Auto-Runner, RYAN_TO_DO Daily Report). Both delivered output that looked plausible to a glance but was actually error text from the agent. The "Last" column in openclaw cron list reports them as ok, hiding the regression from the dashboard view. Same silent-breakage anti-pattern as #75753 — different code path, same UX problem.

Additional information

The local fix is documented in the warning (alsoAllow: ["exec", "process"]). The real fix is making this regression non-silent — either through validation errors on configs that load messaging with tool sections that won't be honored, or by failing the cron run and reporting status: "tool-policy-error" instead of status: "ok".

Companion to #75753 — both ship as 2026.4.29 regressions where the user-visible signal is "my crons stopped working" but no openclaw command surfaces the cause.