Long URL in an issue/PR body is stored wrapped in a code span, breaking the link

Start at the issue_write and update_pull_request entry points, then trace the body-filtering path implicated by the report and compare fresh writes at 103 and 104 characters. Reproduce the markdown link, bare URL, and autolink cases from the issue. Done means long URLs are stored verbatim and render as working links for both write tools.

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):

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.