| name | dm |
| description | Use when sending a short, synchronous dispatch-backed direct message to an owned Codex lane, asking a bounded question, identifying inter-lane sender/target handles, or teaching a target lane to reply in a lightweight chat style. Long name: dispatch message. Not for delegation, background work, heartbeats, or autonomous task ownership. |
DM
Use $dm for a short, synchronous conversation with another dispatch-managed
Codex lane. The long form is "dispatch message": the workflow is backed by
dispatch send, not by a separate dispatch message CLI op in v0.
Use a goal/delegation workflow instead when the target lane should own
background work, source-control follow-through, monitoring, heartbeats, or a
long-running task.
Preconditions
Use dispatch first:
uv run dispatch doctor --no-app-server
uv run dispatch list
uv run dispatch daemon status
If the environment is new, run uv run dispatch doctor once before messaging.
Fix PATH, Codex auth, stale daemon files, registry, or plugin asset warnings
before assuming a DM failure is about the target lane.
The target should be an owned dispatch lane selected by dispatch ref when
possible. Attached lanes are turn-write locked by default. Dispatch permits
DM/send verbs only when local config explicitly enables
[policy] allow_attached_writes = true; check the lane's writable,
capabilities, and write_locked_reason fields before sending.
If the user wants to message an existing desktop Codex thread, attach/sync it
only for observation unless they explicitly enable attached writes after
reading ADR-0005 and ADR-0018.
Handles And URIs
Use bare @Name handles for conversational identity. When the thread id is
known, make the first human-facing mention a Markdown Codex URI. Compose a link
whose label is the handle and whose destination is the Codex URI:
