Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: openclaw agent --deliver silently drops messages (exit 0, no delivery) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#57284•Fetched 2026-04-08 01:51:36
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
joeykrugjoeykrug
Participants
joeykrugjoeykrug
Timeline (top)
referenced ×2cross-referenced ×1

Error Message

  • Silent notification loss: Background automation (coding agents, cron jobs, watchers) that use agent --deliver to notify users silently fail. Exit 0 means no error handling triggers.

Fix Action

Workaround

Use openclaw message send for channel delivery:

openclaw message send --channel signal --target "+1234567890" -m "notification" --json

No workaround exists for direct session injection (agent --session-id).

PR fix notes

PR #57300: fix: agent --deliver bypasses LLM turn, delivers message directly

Description (problem / solution / changelog)

Summary

  • agent --deliver now bypasses the LLM turn entirely and delivers the original --message text directly to the target channel, matching openclaw message send semantics
  • When internalEvents are present (e.g. subagent announcements), the LLM path is preserved so internal context is synthesized into a human-readable summary before delivery
  • Uses opts.message (not body) for direct payloads to avoid leaking internal prompt context
  • --deliver stays on the gateway-first path (channel runtime may be gateway-side); the bypass in agentCommandInternal handles both gateway and local execution

Problem

openclaw agent --deliver --channel signal --to "+1234567890" --message "notification text" silently drops messages (exit 0, no delivery). The LLM turn processes the notification text as a user message and responds with NO_REPLY or an internal response — the actual channel delivery never happens.

Fix

When --deliver is set and no internalEvents are present, construct a synthetic result with the original message as the payload and pass it directly to deliverAgentCommandResult, which handles channel resolution, target validation, and the actual delivery. No LLM turn is spawned.

When internalEvents are present (subagent announcement path via subagent-announce-delivery.ts), the code falls through to the normal LLM path so the internal context is properly summarized before delivery.

Test plan

  • New test: bypasses LLM turn when --deliver is set — verifies runEmbeddedPiAgent is not called and the original message is delivered
  • New test: falls through to LLM when --deliver has internalEvents — verifies LLM is invoked for subagent announcements
  • Updated test: passes through telegram accountId when delivering — now expects original message text instead of LLM response
  • New test: routes --deliver through the gateway — verifies gateway path is preserved for --deliver
  • pnpm build passes
  • pnpm check passes
  • pnpm test passes (3 pre-existing config schema failures on origin/main, unrelated)

Fixes #57284

AI-assisted: Fully tested with pnpm build && pnpm check && pnpm test.

Changed files

  • src/agents/agent-command.ts (modified, +26/-0)
  • src/cli/program/register.agent.ts (modified, +5/-1)
  • src/commands/agent-via-gateway.test.ts (modified, +19/-0)
  • src/commands/agent.test.ts (modified, +72/-1)

Code Example

# This silently fails (exit 0, message never arrives on Signal):
openclaw agent --deliver --channel signal --to "+1234567890" --message "Test notification"

# This works correctly (message arrives immediately):
openclaw message send --channel signal --target "+1234567890" -m "Test notification" --json

---

openclaw message send --channel signal --target "+1234567890" -m "notification" --json
RAW_BUFFERClick to expand / collapse

Bug Summary

openclaw agent --deliver --channel signal --to "+1234567890" --message "notification text" reports success (exit 0) but the message is never delivered to the target channel. The command spawns a full LLM agent turn that processes the notification text as a user message, and the agent either responds with NO_REPLY or generates an internal response — but the actual channel delivery never happens.

Steps to Reproduce

# This silently fails (exit 0, message never arrives on Signal):
openclaw agent --deliver --channel signal --to "+1234567890" --message "Test notification"

# This works correctly (message arrives immediately):
openclaw message send --channel signal --target "+1234567890" -m "Test notification" --json

Expected Behavior

openclaw agent --deliver should deliver the message directly to the specified channel, similar to openclaw message send. It should NOT spawn an LLM turn.

Actual Behavior

  1. agent --deliver spawns a full LLM agent turn
  2. The LLM processes the notification text as if it were a user message
  3. The LLM decides there is nothing to forward (responds NO_REPLY or generates an internal response)
  4. The message is never delivered to the target channel
  5. Exit code is 0 (success), so the caller has no way to know delivery failed

Impact

  • Silent notification loss: Background automation (coding agents, cron jobs, watchers) that use agent --deliver to notify users silently fail. Exit 0 means no error handling triggers.
  • Tier 2 orchestration broken: openclaw agent --session-id <key> --message "..." has the same issue — it injects via LLM turn instead of direct session message injection. This breaks the --notify session:<key> pattern for waking yielded subagents.

Workaround

Use openclaw message send for channel delivery:

openclaw message send --channel signal --target "+1234567890" -m "notification" --json

No workaround exists for direct session injection (agent --session-id).

Environment

  • OpenClaw version: 2026.3.28
  • Channel: Signal
  • OS: Linux 6.12.67 (x64)

Suggested Fix

agent --deliver should bypass the LLM turn and directly invoke the channel plugin send path, similar to how message send works. Alternatively, add a --direct flag that skips the LLM turn.

For session injection, add a message inject --session-key <key> --message "..." command that injects a message into a session without triggering an LLM turn.

extent analysis

Fix Plan

To fix the issue, we need to modify the openclaw agent --deliver command to bypass the LLM turn and directly invoke the channel plugin send path.

Here are the steps:

  • Modify the agent --deliver command to accept a --direct flag.
  • When the --direct flag is present, bypass the LLM turn and directly invoke the channel plugin send path.
  • Add a new command message inject to inject a message into a session without triggering an LLM turn.

Example Code

# Modified agent --deliver command
def deliver_message(args):
    if args.direct:
        # Bypass LLM turn and directly invoke channel plugin send path
        channel_plugin = get_channel_plugin(args.channel)
        channel_plugin.send_message(args.to, args.message)
    else:
        # Existing code to spawn LLM turn

# New message inject command
def inject_message(args):
    session = get_session(args.session_key)
    session.inject_message(args.message)

Verification

To verify the fix, run the following commands:

openclaw agent --deliver --channel signal --to "+1234567890" --message "Test notification" --direct
openclaw message inject --session-key <key> --message "Test notification"

Check if the messages are delivered directly to the target channel and session without spawning an LLM turn.

Extra Tips

  • Make sure to update the documentation to reflect the new --direct flag and message inject command.
  • Test the fix thoroughly to ensure it works as expected and does not introduce any new issues.
  • Consider adding error handling to handle cases where the message delivery fails.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#memory optimization#batch processing#GPU compatibility#latency issue#model loading

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING