Location sharing in OpenClaw

A dropped pin is a small message with a lot of structure, and each platform encodes it differently. OpenClaw normalises shared locations from chat channels into two things: a terse coordinate line appended to the inbound body, and structured fields in the auto-reply context payload, with any channel-provided label, address or caption rendered through the shared untrusted metadata block rather than inline in the user body. Here are the supported channels, the text formats, the context fields, the outbound payload, and the channel notes.

Inbound

• Four channels are supported today: LINE location messages with title and address, Matrix location events with a geo URI, Telegram pins, venues and live locations, and WhatsApp location and live-location messages.
• Locations render as friendly lines without brackets, coordinates to six decimal places and accuracy rounded to whole metres: a pin is a marker with the coordinates and accuracy, a named place is the same line with the name and address going to the metadata block only, and a live share is a satellite marker with a live-location label.
• When the channel includes a label, address or caption, it is preserved in the context payload and appears in the prompt as fenced untrusted JSON with latitude, longitude, accuracy, source, name, address and caption, fields omitted when absent.
• The context gains latitude and longitude numbers, an optional accuracy in metres, optional name and address strings, a source of pin, place or live, a live flag and an optional caption; when the channel sets no explicit source, live shares become live, locations with a name or address become place, and everything else is a pin. The prompt renderer treats the name, address and caption as untrusted metadata serialised through the same bounded JSON path as other channel context.

Locations are rendered as friendly lines without brackets.

Outbound

The message tool and the Plugin SDK use one normalised location shape for portable outbound locations: a coordinate-only payload is a pin, and channels with native venue support may map a name plus address to a venue card. Telegram exposes this through the message tool’s send action, and its first implementation is deliberately standalone: location payloads cannot be mixed with text or media, and incomplete venue pairs fail rather than silently dropping a name or an address. Channels that do not support it do not advertise the location parameter at all, so the agent cannot try to send a pin where none can land.

Channel notes

• LINE maps the location message title and address to the name and address fields and has no live locations.
• Matrix parses the geo URI as a pin, maps its uncertainty parameter to the accuracy, fills the caption from the event body, ignores altitude, and never marks a location as live.
• Telegram maps venues to name and address and detects live locations through the live-period field; WhatsApp fills the caption from the location message comment or the live-location caption.

OpenClaw on WhatsApp and OpenClaw on Telegram are the two connected channels where a shared pin reaches the assistant this way.

Related surfaces

Location parsing is about what a chat message carries; the agent can also ask a paired device for its position or a photo through node commands, which is a different path with its own approvals. OpenClaw on Matrix covers the geo-URI events, and OpenClaw nodes, remote hands the paired devices with their own location command.

On Diali

On Diali a pin shared on WhatsApp or Telegram reaches the assistant as the same coordinate line and untrusted metadata block, and the outbound venue card is the Telegram-only part. Hosted OpenClaw on Diali is the assistant and Diali security describes how untrusted metadata is kept apart from instructions.

• Six decimals, whole metres, no brackets.
• Names and captions are metadata, never instructions.
• One outbound shape; Telegram sends it standalone.