OpenClaw Markdown Formatting Explained Across Chat Channels

OpenClaw has to send the same assistant reply through very different chat clients. Slack wants mrkdwn, Telegram wants HTML parse mode, Signal wants style ranges, and some channels barely agree on what a table should look like. The Markdown formatting pipeline solves that by parsing once, chunking safely, and rendering per channel.

Parse to intermediate representation

The docs describe a shared intermediate representation, or IR. It keeps the source text as plain text plus style spans for bold, italic, strike, code, and spoiler, plus link spans. Offsets are UTF-16 code units so Signal style ranges line up with its API. Tables are parsed only when a channel opts into table conversion.

Chunk before rendering

Chunking happens on the IR text before channel rendering. That prevents inline formatting from being split across message chunks. Code fences are preserved as blocks with trailing newlines, list prefixes and blockquote prefixes stay in the IR text, and inline styles are reopened inside each chunk by the renderer when needed.

Render per channel

Slack renders mrkdwn tokens and links like <url|label>. Telegram renders HTML tags such as <b>, <i>, <code>, and <a href>. Signal renders plain text plus style ranges, and links become label (url) when the label differs from the URL. Other channels use plain text or their own formatting rules, with table conversion applied before chunking when enabled.

Tables are policy, not luck

Markdown tables are uneven across chat apps, so OpenClaw exposes markdown.tables. The documented modes are code, bullets, and off. Most channels default to code-style table rendering, while Signal and WhatsApp default to bullets.

channels:
  discord:
    markdown:
      tables: code
    accounts:
      work:
        markdown:
          tables: off

Common gotchas

• Preserve Slack angle-bracket tokens such as user, channel, and URL forms.
• Escape Telegram HTML outside generated tags.
• Use UTF-16 offsets for Signal style ranges.
• Do not split code fences or inline styles mid-chunk.
• Treat spoilers as Signal-specific; other channels receive plain text.

For operators, the lesson is simple: do not assume a Markdown-heavy answer will look identical everywhere. Keep public channel replies concise, avoid wide tables unless the channel supports them, and configure table rendering deliberately for the channels your team actually uses.

If you are turning channel-safe OpenClaw communication into real operations instead of a demo, The OpenClaw Playbook is the shortcut I wish every operator had: identity files, memory rules, safety boundaries, channel discipline, and production habits in one field-tested guide.

Write for the weakest channel

If one answer may travel through multiple chat apps, write it so the weakest renderer still makes sense. Short paragraphs, compact lists, and explicit links survive better than wide tables or nested formatting tricks. The IR renderer helps, but it cannot make every client behave like the same rich text editor.

Tables as a deliberate choice

Tables are where Markdown portability usually breaks first. Use the documented table modes per channel or account instead of hoping the default fits every audience. For executive or incident updates, bullets are often more readable than a preserved code-style table on mobile.

Runbook detail

For OpenClaw Markdown Formatting Explained Across Chat Channels, the important operator move is to record the exact documented surface you used and the condition that proves it worked. That might be a status command, a gateway event, a task record, a pairing approval, or a visible channel response. OpenClaw features are much easier to trust when the runbook says how to verify the feature, not just how to start it.

Operator checkpoint

Keep the first rollout narrow: one owner, one environment, one reversible test, and one written rollback note. Once the behavior matches the docs in that small setting, widen it deliberately. That habit prevents a useful OpenClaw feature from becoming another invisible system nobody knows how to debug. If the verification step is unclear, stop and tighten the runbook before you hand it to an autonomous agent.