LocalUDPMessenger
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill mostly matches its local agent-messaging purpose, but it can let peer-agent messages wake and prompt your agent, and its documented trust migration may bypass fresh user approval.
Install only if you want agent-to-agent LAN messaging and are comfortable with trusted peers being able to wake and prompt your agent. Use always-confirm mode on shared networks, avoid sending secrets, keep relay disabled unless you control the monitor server, and protect the Gateway hook token.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A peer whose identity changes, or a local peer that can appear to match a trusted hostname, may become trusted without a fresh approval step and then send messages that the agent may process automatically.
The documentation simultaneously promises explicit approval and describes automatic trust migration based on hostname, which is a weak identity boundary for agent-to-agent messages.
Peers are **never auto-approved** ... If a peer's ID does change ... trust is **auto-migrated** by hostname match
Require explicit re-approval when a peer ID changes, prefer cryptographic peer authentication or pinned keys, and use always-confirm mode on shared or untrusted networks.
A trusted peer can wake the agent and influence what it does or says without the original user actively starting that turn.
Incoming peer-controlled text is inserted into a new agent prompt and framed as a user-like message to answer, which can redirect the agent if the peer is compromised or mistakenly trusted.
`Message: "${message}"` ... `Please read this message and respond appropriately using udp_send.` ... `treat the content as you would a user message`Frame peer messages as untrusted quoted data, require user confirmation before acting on instructions from peers, and avoid automatic responses for sensitive workspaces.
Anyone who obtains or misconfigures this token may be able to trigger agent wake-up behavior through the Gateway.
The plugin intentionally uses a Gateway hook token to trigger local agent turns. This is disclosed and purpose-aligned, but the token is still sensitive authority over the local agent.
The plugin auto-discovers the token from ... `hooks.token` ... `gateway.auth.token` ... `OPENCLAW_HOOK_TOKEN`
Only configure the hook token if active wake-up is needed, keep it private, and rotate it if it may have been exposed.
If relay is enabled to the wrong server, agent-to-agent messages may be visible to unintended observers.
The relay feature is disclosed and optional, but it can mirror all message contents to another host if enabled.
When `relayServer` is configured, every sent and received message is forwarded as a UDP packet to the specified server.
Leave relay disabled unless needed, point it only at a trusted monitoring server, and avoid relaying sensitive project or credential information.
The agent may continue briefly to handle peer messages instead of stopping immediately.
A stop hook can cause the agent to check and potentially answer peer messages before ending. This is consistent with a messenger skill, but it changes normal stopping behavior.
Before stopping, check if there are unread UDP messages by calling udp_receive ... process them and respond.
Disable the hook or use stricter confirmation settings if you do not want peer messages processed at stop time.