dm

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 not turn-writable in v0, so dispatch will reject DM/send verbs against them.

If the user wants to message an existing desktop Codex thread, attach/sync it only for observation unless they explicitly choose a different authority model after reading ADR-0005.

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:

label: @Target
destination: codex://threads/<target-thread-id>

Use the dispatch ref or full thread id for dispatch send. Use the URI link in the message body so the recipient and the human can open the thread directly.

Message Shape

Send one small request with a one-line envelope:

From <sender Markdown thread link> to <target Markdown thread link> via $dm:

<freeform message>

Contract: read-only, brief answer, reply in this lane unless asked otherwise.

Then deliver it:

uv run dispatch send <target-ref> '<message>' --intro

Keep DMs conversational and bounded. Prefer one ask. Include only the context needed for the target lane to answer without reading the sender's full transcript. If the current Codex thread is not managed by dispatch, omit --intro and include the sender link manually. Do not use $dm to smuggle in broad implementation work.

Harvesting

dispatch send starts the target turn. Use dispatch get and dispatch daemon log to confirm thread state and accepted actions:

uv run dispatch get <target-ref>
uv run dispatch daemon log --limit 10

Important v0 limitation: dispatch get is thread metadata, not a transcript reader. Use dispatch tail <target-ref> --limit 50 for persisted history when the lane is non-ephemeral, or open the Codex thread link. Do not pretend dispatch harvested text it cannot currently read.

Optional Contract Lines

Use one line only when it reduces ambiguity:

Contract: answer only; no repo/tracker/source-control mutation.
Contract: 3-6 lines; include evidence paths if you check live files.
Contract: sanity-check the wording; no implementation.
Contract: reply back to <sender Markdown thread link> when done.

Guardrails

• Do not use $dm for background execution or task ownership.
• Do not create new lanes unless the user asks.
• Do not pin, archive, rename, or stop lanes as part of ordinary DM flow.
• Do not send secrets, private data, long logs, or unrelated transcript dumps.
• If the exchange becomes work ownership, stop and switch to a goal/delegation workflow.

Example

From <@Docs Markdown thread link> to <@Dispatch Markdown thread link> via $dm:

Quick terminology check: should the usage docs say "lane" everywhere, or is
"thread" acceptable in the operator guide when referring to raw Codex ids?

Contract: read-only; 3-5 lines; include evidence paths if you check repo docs.