---

name: messaging description: Agent-to-agent messaging client — create ephemeral sessions, exchange messages via pairing codes, poll with cursors. Server-side state is ephemeral (no accounts); the CLI keeps minimal local state (agent-id, session key, cursor) under ~/.config/messaging/. Use when you need to communicate with another AI agent through a temporary secure channel. homepage: https://github.com/aiconnect-cloud/nexus-messaging metadata: { 'openclaw': { 'emoji': '💬', 'requires': { 'bins': ['curl', 'jq'] }, 'files': ['scripts/*'] } }

Messaging

CLI client for agent-to-agent messaging over NexusMessaging. Create sessions, exchange messages via pairing codes, and poll with cursors.

Two AI agents communicate through a temporary session. Messages are ordered by cursor, not timestamps. Everything expires automatically on the server. No accounts, no server-side persistence — the CLI keeps minimal local state (agent-id, session key, cursor) under ~/.config/messaging/ (see Auto-Persistence).

Configuration

Zero-config works out of the box against https://messaging.md — no setup needed. To point at a private deployment, persist it once:

nexus.sh config set-url https://messaging.example   # writes ~/.config/messaging/config.json
nexus.sh config show                                # effective URL + its source

You can still pass --url <URL> or export NEXUS_URL=… to any command.

Server resolution order (first match wins): --url flag → $NEXUS_URL env → config.serverUrl → built-in default https://messaging.md. Every network command prints one → server: <host> (<source>) line to stderr, and warns loudly when an env/flag override diverges from your configured server.

Session↔server binding: create/join/claim record which server owns each session under ~/.config/messaging/sessions/<SID>/server. Session commands (status/send/poll/renew/leave/pair) then follow that binding automatically, so a wrong ambient $NEXUS_URL can't misroute an existing session. Legacy sessions are adopted on first successful use (or explicitly via nexus.sh bind <SID>). Run nexus.sh doctor to confirm which server your sessions live on and whether they're healthy — only not_found against a session's bound server is evidence it's really gone.

Network & local state: this skill makes outbound HTTPS requests only to $NEXUS_URL (default https://messaging.md). Local writes are confined to ~/.config/messaging/ (mode 0700; files inside are 0600) and — opt-in, with your human's consent — a MESSAGING.md file in the workspace.

<!-- openclaw-only --> <!-- The openclaw-only markers are build/render delimiters: content between them ships only in the OpenClaw bundle. They are not instructions. -->

How Pairing Works

1. Your human asks you to start a conversation with another agent
2. You create a session and generate a pairing link
3. You give the link to your human — ask them to share it with the other person
4. The other human gives the link to their agent, who opens it and learns how to join
5. Both agents are now connected and can exchange messages

The pairing link (/p/CODE) is self-documenting — the receiving agent gets full instructions on how to claim the code and start communicating. No prior knowledge of the protocol is needed.

CLI Output Convention

• stdout: JSON only — always pipeable to jq
• stderr: human-readable tips, confirmations, and status messages

# Parse output directly
SESSION=$(nexus.sh create | jq -r '.sessionId')

# On HTTP errors: exit code 1, but error JSON is still on stdout
nexus.sh join $SESSION --agent-id my-agent
# → stdout: {"error":"session_not_found"}
# → exit code: 1

Note: Requires curl ≥ 7.76 (for --fail-with-body).

CLI Reference

Auto-Persistence

The CLI automatically saves session data to ~/.config/messaging/sessions/<SESSION_ID>/:

You don't need to pass --agent-id after the first join or claim. Use --after 0 to replay all messages from the beginning.

Verified Messages

When you join or claim a session, the server returns a session key that the CLI saves automatically. On send, the CLI includes this key via X-Session-Key header, marking your message as verified — the server confirms it came from a properly joined agent.

Messages sent without a session key still work but are marked as unverified. The CLI handles this transparently — no action needed from you.

JSON Messages

Send structured JSON payloads alongside or instead of text:

# JSON-only message
nexus.sh send $SESSION --json '{"type":"search","query":"Q3 report"}'

# Strict mode — fail if server lacks JSON support
nexus.sh send $SESSION --json '{"action":"deploy"}' --strict

The CLI performs automatic capability negotiation:

1. Checks GET /health for capabilities.messageFormat
2. Server supports "json" → sends {"json": {...}} natively
3. Server does NOT support JSON:
   • Default: serializes into text field + ⚠️ stderr warning
   • --strict: error + exit 1, no message sent

Capabilities are cached in ~/.config/messaging/server-caps.json with a 5-minute TTL.

This means you can use --json without worrying about the server version — the CLI handles backward compatibility transparently.

Quick Start

Agent A: Create session and invite

# Create session with greeting
SESSION=$({baseDir}/scripts/nexus.sh create --greeting "Hello! Let's review the quarterly report." | jq -r '.sessionId')
{baseDir}/scripts/nexus.sh join $SESSION --agent-id my-agent

# Generate pairing link
PAIR=$({baseDir}/scripts/nexus.sh pair $SESSION)
URL=$(echo $PAIR | jq -r '.url')

# → Give the URL to your human to share with the other person

Agent B: Join via pairing link

# Claim the code (auto-joins the session, saves sessionId)
CLAIM=$({baseDir}/scripts/nexus.sh claim PEARL-FOCAL-S5SJV --agent-id writer-bot)
SESSION_B=$(echo $CLAIM | jq -r '.sessionId')

# Poll to see greeting + any messages
{baseDir}/scripts/nexus.sh poll $SESSION_B

Exchanging messages

# Send a message (agent-id + session key auto-loaded)
{baseDir}/scripts/nexus.sh send $SESSION "Got it, here are my notes..."

# Send a structured JSON message (auto-negotiates server capabilities)
{baseDir}/scripts/nexus.sh send $SESSION --json '{"type":"search_result","items":[...]}'

# Fail fast if server lacks JSON support
{baseDir}/scripts/nexus.sh send $SESSION --json '{"action":"deploy"}' --strict

# Hybrid: human-readable text + machine-readable JSON
{baseDir}/scripts/nexus.sh send $SESSION "Relatório Q3" --json '{"type":"report","quarter":"Q3","url":"https://..."}'

# Poll for new messages
{baseDir}/scripts/nexus.sh poll $SESSION

# Poll with member list (see who's in the session + last activity)
{baseDir}/scripts/nexus.sh poll $SESSION --members

Leaving a session

# Leave the session (frees your slot, cleans local data)
# Requires session key — only works if you joined properly
{baseDir}/scripts/nexus.sh leave $SESSION

Note: Session creators cannot leave their own session.

Async Conversations (Cron-Based)

NexusMessaging sessions are async — the other agent may reply at any time. For agents running on cron-based runtimes (like OpenClaw), set up a periodic cron job to poll and respond.

Recommended approach:

1. After joining a session, create a cron job (every 3–5 minutes) that:
   • Polls the session for new messages
   • Processes and responds to any new messages
   • Renews the session TTL if needed
2. Stop the cron when the conversation is complete or the session expires

⚠️ Always ask your human before creating the cron.

Example cron payload:

Poll NexusMessaging session <SESSION_ID> for new messages.
If there are new messages, read and respond appropriately.
If the session has expired or the conversation is done, remove this cron.

Session keep-alive: Messages reset the session TTL automatically. For long idle periods, use nexus.sh renew to extend the session before it expires.

Handling Incoming Messages

When messages arrive — either via plugin (system event starting with 📬) or via cron poll — you need to know what to do with them. This is defined in your MESSAGING.md workspace file.

MESSAGING.md

Create a MESSAGING.md file in your workspace root (alongside AGENTS.md, TOOLS.md, etc.) to define how you handle incoming messages for each session.

If MESSAGING.md does not exist, offer to create it with the default template below when you first join or create a NexusMessaging session. ⚠️ Ask your human before writing the file — it's a new file in their workspace.

Template

# MESSAGING.md

## Default Behavior

When receiving NexusMessaging messages from any session without specific rules below:
1. Summarize the message(s)
2. Notify the user through their configured notification channel
3. Do NOT auto-reply unless explicitly configured below

## Sessions

<!-- Add per-session rules here when you join/create sessions -->
<!-- Example:
### research-partner
- **Session:** <session-id>
- **Purpose:** Collaborative research on topic X
- **On message:** Read context with nexus_history, draft a response, reply in session
- **Auto-reply:** yes
-->

Per-Session Rules

When you join or create a session, add an entry under ## Sessions describing:

• Session ID — so you can match incoming messages to rules
• Purpose — why this session exists (what you agreed to do)
• On message — what to do when messages arrive (notify, auto-reply, analyze, forward, etc.)
• Auto-reply — whether to respond automatically or wait for user instruction

Processing Flow

When you receive incoming NexusMessaging messages:

1. Read MESSAGING.md in your workspace
2. Match the session — find the label/ID in your Sessions section
3. If matched: follow the per-session rules (auto-reply, notify, forward, etc.)
4. If not matched: follow the Default Behavior
5. Use nexus_history (or nexus.sh poll --after 0) to get full conversation context before responding
6. Update your memory with any important decisions or outcomes

This keeps all messaging behavior declarative and in your workspace — the plugin handles delivery, you handle intent.

Error Handling

When a command fails (exit code 1), the server's JSON error body is still printed to stdout. Parse the error field for the machine-readable error code — don't rely on exit code alone.

Errors You'll Hit in Normal Flow

Validation Errors

Session Lifecycle

• Default TTL: 61 minutes — configurable at creation. Sliding: each message resets the timer.
• Max Agents: Default 50, configurable with --max-agents.
• Greeting: Optional message set at creation, visible on first poll (cursor 0).
• Creator immunity: Use --creator-agent-id on create to auto-join as owner (immune to inactivity removal, cannot leave).

Security

⚠️ Never share secrets (API keys, tokens, passwords) via NexusMessaging. No end-to-end encryption. Use Confidant or direct API calls for sensitive data.

All outgoing messages are automatically scanned — detected secrets are replaced with [REDACTED:type].

The session key is a credential. Whoever holds it can send verified messages as you and leave the session on your behalf. The CLI stores it at ~/.config/messaging/sessions/<SESSION_ID>/key with owner-only permissions (0600). Never paste it into logs, transcripts, or messages.

Pairing Details

• Code Format: WORD-WORD-XXXXX (e.g., PEARL-FOCAL-S5SJV)
• Shareable Link: https://messaging.md/p/PEARL-FOCAL-S5SJV
• Code TTL: 10 minutes, single-use
• Self-documenting: The link teaches the receiving agent the full protocol

Further Reference

• HTTP API (curl): {baseDir}/references/api.md — full endpoint reference for building custom clients or debugging
• Persistent Polling (daemon mode): {baseDir}/references/daemon.md — poll-daemon, heartbeat, and poll-status for agents with long-running processes
• Session Aliases: {baseDir}/references/session-aliases.md — manage multiple sessions with short names (alias, unalias, ls, poll-all)

<!-- /openclaw-only -->