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.
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:
Stored:
The same URL one character shorter stores untouched:
What I varied
Stepping the length by twos, then by ones across the boundary (reproduction):
example.comat 184 wraps exactly asdocs.github.comdoes, and short non-GitHub URLs are untouched<and>are additionally escaped to entitiesissue_writeandupdate_pull_requestbehave alikeWhere 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.