GitHub MCP server drops tag-shaped content from issue-body reads — decide whether to report upstream

[mmcky]

Decision record: whether to report a GitHub MCP server defect upstream. The hazard itself is closed out locally (QuantEcon/cli#32); this issue holds the one deferred call.

The defect

Reading an issue body through the GitHub MCP server returns a sanitised rendering, not the stored source. Entities are substituted (" → ", ' → ', > → >) and — the damaging part — anything shaped like an HTML tag is dropped entirely, silently, with no marker: <placeholder>, <owner/repo>, <parent>, <N>, <label>. An issue-body edit performed from such a read is a silent content-destroying operation: it faithfully preserves everything else while deleting every placeholder, undetectable in the diff unless you already know to look.

Full analysis: QuantEcon/qeps#19 (amendment 7 addition).

What the audit established (QuantEcon/cli#32, closed 2026-08-27)

Every body suspected of exposure was pulled raw via gh issue view --json body and inspected: no damage anywhere — all placeholders intact in storage across QuantEcon/cli #11/#14/#20/#24/#27–#31 and the QuantEcon/qeps #19/#20 bodies and comments. The loss is confirmed read-side only; the write path is faithful. Two bodies edited from raw reads round-tripped byte-identically with placeholders verified after the write.

Interim protection is in place and recorded on cli#32: read with gh issue view <N> --json body --jq .body, write with gh issue edit <N> --body-file, verify with a read-back diff — and never edit a body from an MCP-surface read.

The decision this issue holds

Whether to file against github/github-mcp-server. The case for filing: sanitising a body for HTML safety is defensible, but doing it on a field whose documented use includes round-tripping, with no flag for raw output and no indication that content was removed, is a silent-data-loss bug that will bite any agent tooling that edits bodies from MCP reads — not just ours.

Precondition before filing, per cli#32: reproduce against the current release from an MCP-equipped session (read a body containing a literal <foo> through the server, observe it missing from the returned text), so the report is against present behaviour rather than a possibly-fixed version.

Outcomes to choose between:

1. File upstream — after the reproduction confirms it, with the qeps#19 evidence table as the report's core.
2. Don't file — rely on the recorded local procedure and close this with that disposition noted.

Either way this issue records where the analysis lives, so the context survives the deciding-later.