Summary

hasPollCreationParams previously treated any of the shared poll params (pollQuestion, pollOption, pollDurationHours, pollMulti) as poll intent if present with a non-zero / non-default value.

The shared message tool schema exposes those last two for both send and poll actions, and agent models routinely echo the schema's implied defaults (1 for the minimum: 1 integer, false for the boolean) on every plain send call alongside the rest of the schema-padded slots. The validator interpreted pollDurationHours: 1 on its own as "the agent meant to create a poll", so runMessageAction threw:

Poll fields require action "poll"; use action "poll" instead of "send".

…on routine sends, blocking agent replies from any channel whose outbound goes through runMessageAction (i.e. all of them). I first observed this on the Slack channel — Slack is where the regression surfaced for our deployment — but the bug is in shared/core code (src/poll-params.ts, used by src/agents/tools/message-tool.ts and src/infra/outbound/message-action-runner.ts), so the same tool-call shape would hit Telegram, Discord, or any other channel a message-tool agent talks to.

This PR narrows the shared-param branch to the content-bearing fields (pollQuestion, pollOption). Channel-extra poll* params (pollDurationSeconds, pollPublic, pollAnonymous, …) remain strict because they aren't part of the shared tool-schema surface, so an explicit value still signals deliberate intent.

What changed

• src/poll-params.ts — split shared-param handling: only pollQuestion / pollOption count as standalone intent. Channel-extra detection is unchanged.
• src/poll-params.test.ts — updated two existing assertions and added a new test for the schema-pad shape.
• src/infra/outbound/message-action-runner.send-validation.test.ts — added an integration case asserting runMessageAction accepts a send with schema-padded pollDurationHours: 1 / pollMulti: false.

Behavior change for existing assertions

Two unit-level assertions changed semantics, both intentionally:

Channel-extra equivalents (pollAnonymous: true, pollPublic: true, pollDurationSeconds: -5) are unchanged and still count as intent, because they are not part of the schema-padded surface that agents echo on every send.

Alternative considered

A more invasive fix would be to make the shared message tool schema action-aware: drop pollDurationHours / pollMulti from the send action's parameter surface entirely so agents never see them when calling send. That addresses the root cause ("LLMs echo schema-implied defaults on every call") instead of catching it at the validator. It's a bigger schema-side change touching buildMessageToolPollProps and the action-to-schema mapping. Happy to take that direction if maintainers prefer it; this PR is the minimal locality-of-change fix at the validator gate.

Real behavior proof

Behavior or issue addressed: hasPollCreationParams returned true for { pollDurationHours: 1 } alone — the value LLMs schema-pad onto every send tool call (the schema is Type.Optional(Type.Integer({ minimum: 1 }))). runMessageAction then threw Poll fields require action "poll"; use action "poll" instead of "send", blocking the send. First surfaced as an agent that could no longer reply in any Slack thread it was @mentioned in; the same tool-call shape would affect every channel that routes through runMessageAction.

Real environment tested: OpenClaw 2026.5.28 (npm openclaw@2026.5.28), running in a production container openclaw-… on a Coolify host. Agent model openrouter/openrouter/auto (thinking=high). Slack channel via socket mode. Same bundled validator code path as upstream main: dist/message-action-runner-*.js calling hasPollCreationParams from the bundled poll-params module.

Exact steps or command run after this patch: I applied the equivalent semantic narrowing in the running container's bundled dist/message-action-runner-*.js via a small node patch script (guard the throw on pollQuestion non-empty OR pollOption non-empty), docker restart-ed the container, then @mentioned the agent in a Slack thread to elicit the same tool-call shape that previously failed.

Evidence after fix: redacted runtime logs and copied live output from the patched container. Failing tool-call shape captured from the pre-patch agent session transcript (10 occurrences in a single failed session, one shown, sensitive IDs redacted to …):

{
  "action": "send",
  "channel": "slack",
  "target": "channel:C…",
  "message": "<@U…> hi",
  "threadId": "…",
  "pollQuestion": "",
  "pollOption": [],
  "pollDurationHours": 1,
  "pollMulti": false
}

Before patch: every such call threw Poll fields require action "poll"… and no reply was delivered. After patch + docker restart, the gateway's runtime log showed clean startup and the message went out without the validator error:

[gateway] http server listening (10 plugins: …, slack, …; 3.7s)
[slack] [default] starting provider
[slack] channels resolved: … (+21)
[slack] socket mode connected
[gateway] ready

The same tool-call shape (with pollDurationHours: 1, pollMulti: false) then went through runMessageAction and produced a delivered Slack message — no Poll fields require action "poll" thrown, no rejection in the outbound path.

Observed result after fix: agent replied in-thread in Slack with the user-facing text. Outbound delivery completed with the workspace plugin returning a Slack message id. The validator no longer blocks schema-padded send calls.

What was not tested: I did not write a full end-to-end test against a real Slack workspace inside this PR's CI — the regression observed in the live container is the proof. I also did not exercise channels other than Slack (Telegram, Discord, …) for the same shape, though the failing code path is channel-agnostic and the integration test in message-action-runner.send-validation.test.ts uses the channel-agnostic runDrySend helper.

Local test results on this PR

Vitest 4.1.7, node 22.18.0, pnpm 11.2.2:

Changed-files lanes (node scripts/test-projects.mjs --changed origin/main):

• vitest.unit-fast.config.ts: 1/1 file, 11/11 tests pass
• vitest.infra.config.ts: 1/1 file, 24/24 tests pass (includes the new integration assertion)

Shared-surface lanes (pnpm test:contracts):

• vitest.contracts-channel-registry.config.ts: 11/11 files, 29/29 tests pass
• vitest.contracts-channel-session.config.ts: 11/11 files, 34/34 tests pass

The plugin-contracts portion of pnpm test:contracts (vitest.contracts-plugin.config.ts) stalled with no output on my machine and was killed by the runner's watchdog; the touched files are not referenced by that lane, but flagging it for CI to confirm.

AI assistance disclosure

• AI-assisted (Claude / Claude Code). I read the failing transcript, the validator, the tool-schema callsite, and the existing tests; chose the narrowing scope; wrote the fix and tests; ran the targeted Vitest shards and the channels-contracts lane.
• Real-behavior proof above is from my own OpenClaw deployment, not from AI-generated mocks.
• I understand what the code does — the change is a strict subset of the previous logic for content-bearing inputs: any input that returned true before still returns true, except shared-modifier-only inputs that match the schema-pad shape.