RFC 0005: Approval Prompt Markdown Contract#4
Merged
Conversation
Propose core plugin SDK emit a canonical markdown subset for approval prompt text, with each channel opting in to render it natively or downgrade losslessly to plaintext. Default is plaintext so the change ships safely channel by channel. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
Codex review: needs real behavior proof before merge. Reviewed May 30, 2026, 7:31 PM ET / 23:31 UTC. Summary Reproducibility: not applicable. this is an RFC PR, not a runtime bug report. I checked current main and the proposed document instead of trying to reproduce behavior. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Review this as an RFC design decision and merge it if maintainers accept the markdown/plaintext approval contract; implementation should happen later in focused OpenClaw core and channel PRs. Do we have a high-confidence way to reproduce the issue? Not applicable; this is an RFC PR, not a runtime bug report. I checked current main and the proposed document instead of trying to reproduce behavior. Is this the best way to solve the issue? Yes for an RFC-stage change: adding a focused design document is the maintainable way to discuss the approval markdown contract before code lands. The actual SDK/channel implementation still needs maintainer design acceptance and later focused PRs. AGENTS.md: not found in the target repository. Codex review notes: model gpt-5.5, reasoning high; reviewed against fb2bfbdbb6c1. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🐚 platinum hermit
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds RFC 0005: a defined markdown contract for approval prompt text.
Approval prompts are built once in core and sent verbatim to every channel.
The builders emit mostly plain text, but an ad hoc markdown subset already
leaks in for exec approvals (
buildFencecode blocks, inline-code ids insrc/infra/exec-approval-reply.ts), and channels render that stringinconsistently. Meanwhile iMessage already converts a markdown subset to
native typed-runs on send, so the rendering machinery exists and sits unused
for approvals.
Proposal
**bold**,_italic_,~~strike~~, inline code, fenced code) deliberately, and ships a losslessdowngradeApprovalMarkdownToPlaintexthelper.approvalText: "markdown" | "plaintext"capability.
markdownchannels translate to native styling and own theirescaping;
plaintextchannels downgrade losslessly.plaintext, so behavior is unchanged until a channel opts in. Noflag day; plaintext is a permanent supported end state.
Rationale
Keeps formatting policy in core and rendering in channels, matching the
repo rule that core stays channel-agnostic. The RFC weighs three alternatives
(iMessage-local only, naive shared-markdown with no opt-in, fully structured
segments) and explains why the opt-in middle path ships safely channel by
channel.
Notes
rfcs/0005-approval-prompt-markdown.md. No code changes; thisis a design proposal.
rfcs/0000-template.md;0005is the next sequential id.