OpenClaw "Action Send Requires a Target": What It Means and How to Fix It

TL;DR: OpenClaw’s “requires a target” error means the message action you ran was refused before it tried to send anything, because no target, or no usable target, was supplied. It is one of six related outbound errors, all denials, not failures, so there is no partial send to clean up. Read the exact wording you got (the action name varies), match it to the right row below, and supply the target it is asking for.

Contents

• The Error
• It Is a Template, Not a Fixed String
• Denied, Not Failed: Nothing Was Sent
• The Six “Requires a Target” and message_target Errors
• Two Messages, One Code
• Why the Hint Text Looks Different Each Time
• How to Fix Each Cause
• When It Is Not This At All
• Key Takeaways

The Error

You ask OpenClaw to send a message and instead of it going anywhere, you get refused with something like:

Action send requires a target.

This means the send action you ran needs to know where it is going, and you did not tell it, so OpenClaw stopped the call before it did anything. Nothing was sent, nothing was queued, and nothing needs to be undone.

That second point is worth repeating on its own, because the phrasing reads like a failure report and it is not one. It is a refusal, issued before delivery was even attempted.

It Is a Template, Not a Fixed String

The message you see is not a single hardcoded sentence. Internally it is built from a template: Action ${action} requires a target. OpenClaw fills in the name of whatever action you actually invoked.

send is the action most people hit this on, which is why “action send requires a target” is the wording most people search for. But the same underlying error applies to any message action run without a target. If you invoked a different action, the sentence you saw will name that action instead, and searching the generic phrase “requires a target” rather than your exact wording will get you closer to an answer than searching your action name alone.

This matters practically: if you are grepping logs, matching on the fixed portion of the sentence (“requires a target”) is more reliable than matching on the whole line, because the whole line changes with the action name.

Denied, Not Failed: Nothing Was Sent

Every error in this family, all six of them, is a MessageActionDeniedError. Denied, not failed. The distinction is not pedantic, it changes what you do next.

A failed send is something that left the building and then broke, which is why a failed send usually comes with questions about duplicates, retries and partial delivery. A denied send never left. OpenClaw validated the call, found it insufficient, and stopped. There is no message in flight, no duplicate to chase down, and no cleanup required beyond fixing the call and running it again.

This is the first thing worth confirming when you see “requires a target” or any of its five siblings, and it is the one thing the raw error response does not spell out for you.

The Six “Requires a Target” and message_target Errors

All six errors below come from the same outbound-target validation in OpenClaw. This is the whole family: if a message-targeting error does not appear in this table, you are looking at something else.

Two of the six carry the exact “requires a target” wording. The other four use different language (ambiguous, unknown, reserved, or a caller-supplied message for the invalid case) but belong to the same message_target family and are denied for the same underlying reason: OpenClaw could not establish a valid destination for your message before it would proceed.

Two Messages, One Code

Look closely at the first two rows in the table above. Action ${action} requires a target. and Delivering to ${provider} requires target${hint} are two different sentences, and both report the identical code: message_target_missing.

They are not the same situation. The first fires when no target was supplied at all, full stop. The second fires when OpenClaw expected to be able to work out a target on its own for that provider and still came up empty. Same code, different cause.

If you are building automation, alerting, or a dashboard that matches on the code field, this is where it will mislead you. message_target_missing alone tells you the class of problem. Only the message text tells you whether you forgot the target entirely or the provider simply could not infer one. Match on the message, not just the code, if the distinction matters to what you do next.

Why the Hint Text Looks Different Each Time

Each of these errors can carry an additional hint, and the hint is formatted inconsistently on purpose. When there is no hint to add, nothing is appended and the sentence ends where it reads above. When there is a hint for the ambiguous, unknown, or reserved cases, it is appended as " Hint: <text>", with the word “Hint” spelled out. When there is a hint for the missing-target case, it is appended as a bare " <text>", with no “Hint:” label at all.

The practical effect is that the same underlying error can look longer or shorter depending on whether a hint was available, and a search for the literal word “Hint:” in your logs will only catch three of the six error types, not all of them. If you are writing a log filter, match on the fixed part of the message (requires a target, message_target) rather than on the presence of the word “Hint”.

How to Fix Each Cause

Each row in the table has its own fix, and they are all variations on the same instruction: give OpenClaw an unambiguous destination before you ask it to deliver.

No target given at all (message_target_missing, first form). You ran a message action and did not supply a target. Supply an explicit target with the call. This is the plain “requires a target” case and the most common one.

Provider could not infer a target (message_target_missing, second form). The provider needed a target and none could be determined from context. Supply the target explicitly rather than relying on the provider to infer it.

Invalid target (message_target_invalid). The target you supplied did not pass validation. The specific reason is caller-supplied, so read the actual message text you received rather than assuming it is the same as a missing target: it will tell you what about the value was unacceptable.

Ambiguous target (message_target_ambiguous). The name you gave matches more than one possible destination for that provider. Provide a unique name, or supply an explicit id instead of a name, so there is nothing left to disambiguate.

Unknown target (message_target_unknown). The name or id you gave does not match anything OpenClaw can find for that provider. Check the value for typos, and confirm the target actually exists and is reachable from the provider in question.

Reserved target (message_target_reserved). The value you supplied is one OpenClaw treats as a reserved word and will not accept as a literal destination. Provide an explicit id or handle instead of the reserved literal.

In every case, the fix is the same shape: replace an implicit, missing, or unusable target with an explicit one that names exactly where the message should go.

When It Is Not This At All

If the error you are looking at does not appear in the six-row table above and does not carry a message_target_* code, it is not part of this family and the fixes here will not apply. A connection failure, an authentication rejection, or a provider-side delivery failure are different problems with their own error paths, and none of them are denials issued before an attempt: they happen after OpenClaw already tried to act.

The clearest tell is the code. If your error carries message_target_missing, message_target_invalid, message_target_ambiguous, message_target_unknown, or message_target_reserved, you are in the right place. If it does not, start with a broader look at OpenClaw errors explained rather than assuming this is a variant of the same thing.

If you have already ruled out a targeting problem and you suspect something deeper in the install itself, the OpenClaw doctor fix guide walks through the built-in diagnostic, and OpenClaw production gotchas covers the failure modes that tend to show up only once an install is running real traffic.

Key Takeaways

• “Requires a target” is a template, not a fixed sentence. The action name changes; the phrase “requires a target” does not, so match on that when searching or filtering logs.
• All six errors in this family are denials, issued before delivery. Nothing was sent, so there is nothing to retry as a duplicate and no partial delivery to clean up.
• Two different messages, missing-target-for-the-action and missing-target-for-the-provider, share one code: message_target_missing. Match on the message text, not the code alone, if you need to tell them apart.
• The hint text is formatted inconsistently by design: labelled Hint: for ambiguous, unknown and reserved targets, unlabelled for the missing-target case, and absent entirely when there is nothing to add.
• The fix for every row is the same shape: replace a missing, ambiguous, unknown, invalid, or reserved target with an explicit one.
• If the error is not one of the five message_target_* codes, it belongs to a different family entirely and this guide will not fix it.

Need help running OpenClaw in production?

Kaxo runs OpenClaw agents in production, including the outbound-message validation that throws errors like this one before a bad call ever reaches a delivery attempt. If message-targeting failures are showing up in your logs and you want them caught and routed correctly instead of surfacing as confusing denials, book a discovery call to scope it, or see how we approach AI agent development . For the wider catalogue of failures, start with OpenClaw errors explained .