fix(server): tell agents how to nest fenced code inside code blocks - #10908
fix(server): tell agents how to nest fenced code inside code blocks#10908pc-style wants to merge 1 commit into
Conversation
A code block whose body contains triple backticks was rendered broken in chat: the inner closing fence ended the outer block, and the rest spilled out as prose. That is correct CommonMark, so the fix is to tell every provider up front to use a longer fence in that case. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — The change adds a focused sentence to shared agent instructions so nested fenced code renders correctly, plus a test verifying the guidance. It affects response formatting across existing providers but introduces no new workflow, schema, deployment, security, or static-analysis behavior. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthrough
ChangesRuntime instruction guidance
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to Runtime instructions now explain safe nested CommonMark fencing, reducing malformed code-block rendering without changing parser or renderer behavior. The change is ready to merge. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
What Changed
One sentence added to the shared runtime instructions that every provider adapter appends (Codex, Claude, Cursor, Grok, OpenCode, Antigravity): a code block that itself contains triple backticks must be fenced with four backticks or
~~~. No parser or renderer change.Why
When an agent replies with a code block containing a fenced block (a prompt to paste, a README snippet), the chat renders it broken: the inner closing fence ends the outer block and the rest spills out as prose. The renderer is right, that is standard CommonMark. The agent just never knew it needed a longer fence. Diverging from CommonMark in the renderer would break copy and paste round trips with GitHub and every other markdown surface, so the fix is to tell the agent.
UI Changes
The change is in what the agent emits, so the visible effect is in how replies render. Both captures below use the same ordinary prompt in a fresh thread with Codex (GPT-5.6), nothing about fences in the prompt:
Before, server on
main: the reply opened with a triple-backtickmarkdownfence. The first innerbashfence closes it, the rest of the README renders as prose, and a stray emptytextblock is left at the end.After, server on this branch: the reply opened with a four-backtick fence and renders as one block with all six inner fences intact.
Streaming the after reply, sped up:
after-readme-streaming-fast2.mp4
Validation:
vp test run apps/server/src/provider/RuntimeInstructions.test.tspasses (6 tests, including a new one for the guidance)```markdown, after starts withmarkdown ````Checklist