GitHub MCP truncates an issue body at a literal <script token — the card reads fine on the web and short through the API #9557

Found by a dispatched dev on objectstack-ai/docs.objectos.ai#67 and reproduced from the PM seat. Filed unassigned.

What happens

An issue whose body contains the literal text `<script` comes back truncated at exactly that byte through issue_read and list_issues. The stored body is intact — the web page renders in full.

Reproduced on objectstack-ai/docs.objectos.ai#67:

• issue_read returns the body cut off mid-sentence at `…MDX component names unchanged, no `` — everything from there on is gone, which is the entire Required outcome and Constraints sections.
• Fetching the rendered page confirms both sections are present and the body ends with "This card is filed unassigned and stays in the backlog until that is settled."

So the damage is in the read path, not in storage.

Why it matters more than it looks

The dispatch protocol already has a repair-first rule for cards whose body is truncated by the sanitizer, and its remedy is to repair the card. That remedy is wrong for this failure mode and would make things worse: the card is not damaged, so "repairing" it means rewriting a body that was already correct, and it would have to be rewritten to avoid a token that any card about input validation, XSS, or content sanitising will naturally contain.

The real exposure is silent spec loss. A dispatched agent that reads its card through the API gets a body that ends at a plausible-looking sentence boundary with no error and no marker. On objectstack-ai/docs.objectos.ai#67 the truncated portion held three non-negotiable constraints (zero-dependency, locale list read from the authority file, every rule demonstrated able to fail). An agent working from the truncated read would have implemented a different card and had no way to know.

Two things made this visible rather than costly, and neither is a control:

• the dispatch prompt told the dev to read the issue on GitHub itself and explicitly verify the body was not truncated — that instruction is the only reason it was caught;
• the card happened to be about <script, so the truncation landed somewhere conspicuous.

What is not yet known

• Whether other tokens trigger it (<iframe, <style, on*=, other HTML-ish opens), or whether <script is special.
• Whether it affects comment bodies as well as issue bodies. The comments on that card render and read fine, but none of them contains the token.
• Whether PR bodies read through pull_request_read behave the same way.

Each is a one-line probe against a scratch issue; the answer changes how wide the guidance has to be.

Interim guidance, until someone measures the above

⛔ Do not repair a card that reads short through the API before checking the rendered page — the card is probably fine and the read is not.

Keep the "read the card on GitHub yourself and verify it is not truncated" clause in dispatch prompts. It is currently the only thing standing between a truncating read and an agent silently building the wrong thing.