Summary
In the desktop app's Plan canvas (the built-in markdown viewer/editor), a fenced code block that has a language info-string on its opening fence (e.g. ```csharp) is not closed by a bare closing fence (```). The renderer treats the bare closing fence as content and leaves the code block "open," so the entire remainder of the document renders as code — headings (##), blockquotes (>), lists, and inline code all stop being parsed as markdown.
Per the CommonMark spec §4.5, a closing code fence must not carry an info string; a bare ``` is the correct way to close a ```csharp block. VS Code (and GitHub itself) render all the variations below correctly, so the file is valid — the app's renderer is non-conformant.
Repro
Open any .md file in the app's Plan panel containing:
- Opening fence with a language tag (
```csharp)
- Some code lines
- A bare closing fence (
```)
- Followed by a heading / blockquote / more markdown
Observed behavior by variant (same content, only the fences changed):
| Opening fence |
Closing fence |
App Plan renderer |
VS Code |
bare ``` |
bare ``` |
Minor glitch: a stray ``` line leaks out, but content after the block recovers |
✅ correct |
```csharp |
bare ``` |
Broken: bare closer not matched → the block never closes and the entire rest of the document renders as code |
✅ correct |
| 4-space indented block (no fences) |
n/a |
✅ correct |
✅ correct |
Expected
A bare ``` closing fence should close a language-tagged opening fence (```csharp), matching CommonMark and VS Code. Content after the block should resume normal markdown parsing.
Actual
The language-tagged block is only closed by an identically-tagged fence; a spec-correct bare closer is swallowed as content, breaking rendering for everything below the block.
Workaround
- Use an indented (4-space) code block instead of a fenced one, or
- Omit the language info-string so both fences are bare (this still leaks a stray
``` line but at least doesn't break the rest of the doc).
Environment
- GitHub Copilot desktop app, version 1.0.71
- OS: Windows 11
- Surface: Plan canvas (markdown viewer/editor),
media=text/markdown
Notes
Screenshots demonstrating all three variants (app vs. VS Code side-by-side) are available and can be attached to this issue.
Summary
In the desktop app's Plan canvas (the built-in markdown viewer/editor), a fenced code block that has a language info-string on its opening fence (e.g.
```csharp) is not closed by a bare closing fence (```). The renderer treats the bare closing fence as content and leaves the code block "open," so the entire remainder of the document renders as code — headings (##), blockquotes (>), lists, and inline code all stop being parsed as markdown.Per the CommonMark spec §4.5, a closing code fence must not carry an info string; a bare
```is the correct way to close a```csharpblock. VS Code (and GitHub itself) render all the variations below correctly, so the file is valid — the app's renderer is non-conformant.Repro
Open any
.mdfile in the app's Plan panel containing:```csharp)```)Observed behavior by variant (same content, only the fences changed):
`````````line leaks out, but content after the block recovers```csharp```Expected
A bare
```closing fence should close a language-tagged opening fence (```csharp), matching CommonMark and VS Code. Content after the block should resume normal markdown parsing.Actual
The language-tagged block is only closed by an identically-tagged fence; a spec-correct bare closer is swallowed as content, breaking rendering for everything below the block.
Workaround
```line but at least doesn't break the rest of the doc).Environment
media=text/markdownNotes
Screenshots demonstrating all three variants (app vs. VS Code side-by-side) are available and can be attached to this issue.