Repository navigation
Long URL in an issue/PR body is stored wrapped in a code span, breaking the link #3299
Description
A URL of 104 characters or more, written into an issue body or pull request description through the MCP, is stored wrapped in a double-backtick code span. At 103 characters and below it stores verbatim.
The link is then broken on GitHub itself, not only in a read-back through the server — the rendered page shows a code span where the link should be.
Reproduction
Write a body containing a markdown link whose destination is 104 characters or longer, then read the stored body back through the REST API, so that the read path is not part of the picture.
Sent:
[link](https://example.com/T104-0123456789012345678901234567890123456789012345678901234567890123456789012345678)
Stored:
[link](``https://example.com/T104-0123456789012345678901234567890123456789012345678901234567890123456789012345678``)
The same URL one character shorter stores untouched:
[link](https://example.com/T104-012345678901234567890123456789012345678901234567890123456789012345678901234567)
What I varied
Stepping the length by twos, then by ones across the boundary (reproduction):
| Variable | Result |
|---|---|
| Length | 104 is the boundary — 96, 98, 100, 101, 102 and 103 store clean; 104, 106, 108, 128, 148, 168 and 188 all wrapped |
| Host | Irrelevant — example.com at 184 wraps exactly as docs.github.com does, and short non-GitHub URLs are untouched |
| Construct | Irrelevant — markdown link destination, bare URL and autolink all wrap; an autolink's < and > are additionally escaped to entities |
| Write tool | Both — issue_write and update_pull_request behave alike |
Where the closing backticks land varies with length: inside the link's parentheses around 104 to 130, and outside them, swallowing the ), from about 148 up.
One consequence worth noting: because the behaviour applies to a bare URL as well as a link destination, an MCP client cannot post this report with a working example in it — the example is corrupted by the behaviour being reported. This body was pasted by hand for that reason.
Not the same as #3165
That one is a read-modify-write persisting a lossy read, and states that a fresh write does not trigger it. Here the body is composed fresh and never read first, and there is a clear length threshold, neither of which that issue describes.
It may be a side effect of the newer body-filtering work (#3035, #3177) preserving a long token by wrapping it rather than deleting it, but I have not verified that and cannot tell which server version served these calls.
Observed 2026-09-17 through the remote MCP endpoint, driven from Claude Code.
Activity
A-RYAN-1 commentedon Oct 9, 2026
The open-source server does not seem to be the layer that wraps the URL. I pointed a local build of v2.0.1 at a fake API (
--gh-host) and sentissue_writebodies with 103, 104 and 184 character URLs as a link, a bare URL and an autolink: every request body reached the API byte for byte, with no backticks. The write path only type-checksbody(normalizeIssueStrings), andpkg/sanitizeruns on read surfaces.Since you saw it through the remote endpoint, the wrapping is likely in the hosted layer in front of this server, or in the client before the call. Happy to share the probe scripts.