openclaw - 💡(How to fix) Fix BTW usage string `<side question>` placeholder eaten by markdown channels [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62877Fetched 2026-04-09 08:01:20
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Participants
Timeline (top)
referenced ×1

Code Example

const BTW_USAGE = "Usage: /btw <side question>";

---

Usage: /btw

---

const BTW_USAGE = "Usage: \`/btw <side question>\`";

---

const BTW_USAGE = "Usage: /btw \\<side question\\>";
RAW_BUFFERClick to expand / collapse

Problem

commands-btw.ts:7 defines:

const BTW_USAGE = "Usage: /btw <side question>";

When a user sends /btw with no question, this string is returned to the channel as-is. Channels that render replies as markdown (e.g. dingtalk, slack, anything HTML-based) interpret <side question> as an unknown HTML tag and strip it, so the user sees:

Usage: /btw

Verified on dingtalk channel today via real-device test.

Why fix it in openclaw

Channels are transparent passthroughs — they receive a markdown string and cannot disambiguate <side question> (placeholder) from <https://example.com> (autolink) from a literal HTML tag. Only the producer (openclaw) knows the semantics. Globally escaping < > in the channel would break legitimate autolinks.

Suggested fix

Wrap the placeholder in backticks so it survives markdown rendering:

const BTW_USAGE = "Usage: \`/btw <side question>\`";

Or escape:

const BTW_USAGE = "Usage: /btw \\<side question\\>";

Backticks are preferred — they also visually distinguish the command from prose.

Scope

Likely the same pattern exists for other slash-command usage strings (`/stop`, `/approve`, …). A quick grep for `Usage:` and `<.*>` in command handler text would catch them.

extent analysis

TL;DR

Wrap the placeholder in backticks or escape the angle brackets to prevent markdown rendering issues.

Guidance

  • Identify all slash-command usage strings that contain placeholders with angle brackets (< and >) and apply the suggested fix to each one.
  • Use backticks (`) to wrap the placeholder, as this is the preferred method for visually distinguishing the command from prose.
  • Alternatively, escape the angle brackets using a backslash (\) if backticks are not suitable.
  • Perform a grep search for Usage: and <.*> in command handler text to catch all instances of this pattern.

Example

const BTW_USAGE = "Usage: `/btw <side question>`"; // using backticks
const BTW_USAGE = "Usage: /btw \\<side question\\>"; // using escaped angle brackets

Notes

This fix assumes that the issue is limited to markdown rendering in channels and that the suggested fix does not introduce any other compatibility issues.

Recommendation

Apply the workaround by wrapping the placeholder in backticks, as this is the preferred method for its visual benefits and effectiveness in preventing markdown rendering issues.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING