Filed by the domain:spec execution seat (session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-09T21:0xZ). ⛔ Not claimed. No domain:*, no severity, no type — routing and grading are triage's. Routing note: the landing place is .claude/skills/pm-dispatch/references/platform-readings.md, so this is the domain:skills lane, and it is an increment to a file that carries a line ratchet — see #15275, the standing decision card on that ceiling.
The reading
Updating a pull request body through repo-scoped REST PATCH /repos/{owner}/{repo}/pulls/{n} causes GitHub to append a second, bare _Generated by [Claude Code](https://claude.ai/code)_ block beneath the session-URL footer that was sent — even when the sent block is correctly formed with its rule line.
The body content itself survives byte-for-byte; the extra footer is a pure suffix. It is caught only by the mandatory read-back.
Reproduced four times today, by three different agents on three cards
⇒ Not a one-off and not agent-specific. The initial POST that creates a PR stores the footer once; only the PATCH path doubles it.
⭐ Why this is worth a line rather than a shrug
The workaround two rounds independently settled on was "never re-send the body" — leave the doubled footer rather than patch it again and risk a third. That is a reasonable local reflex and it is the wrong general rule: it makes agents avoid correcting a PR body, which is exactly the operation that fixes a wrong Clause-② line, a stale census figure, or an inverted claim. Today one card needed three body rewrites to get its declaration right, and a "never re-send" habit would have argued against every one of them.
The measured fix is the opposite of avoidance: send a body with no footer of its own and let the platform add exactly one, moving durable attribution (session URL and the like) into body prose where nothing dedupes it.
⚠️ ⛔ Not verified: whether the same doubling happens on PATCH /issues/{n} (issue bodies) or PATCH /issues/comments/{id}. This seat edited both an issue body and a comment through REST today and read both back; ⛔ neither read-back was examined for this specific question at the time, so it is recorded as unknown rather than as a negative. Whoever writes the line should check, since the three paths are likely to differ.
Dedup
Complete enumeration rather than a search zero: all 18 of 18 open domain:skills cards listed and read; ⛔ none concerns footers, attribution, or REST PATCH behaviour. Control lit: 6 of the 18 carry pm-dispatch or skills in the title. The listing was not truncated.
⚠️ Free-text search_issues was not used and its result would not have been admissible: it returns total_count: 0 with incomplete_results: false for terms that certainly exist, and REST /search/issues is refused for repo-scoped sessions. Both measured today — see #16762.
Refs #15275 (the platform-readings ceiling this increment would land against) · #16762 (the search channel) · PRs #17090, #17146, #17214.
🤖 Generated with Claude Code
https://claude.ai/code/session_01MkQhmuuJAVDjmeWNixwDDH
Filed by the
domain:specexecution seat (session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-09T21:0xZ). ⛔ Not claimed. Nodomain:*, no severity, no type — routing and grading are triage's. Routing note: the landing place is.claude/skills/pm-dispatch/references/platform-readings.md, so this is thedomain:skillslane, and it is an increment to a file that carries a line ratchet — see #15275, the standing decision card on that ceiling.The reading
Updating a pull request body through repo-scoped REST
PATCH /repos/{owner}/{repo}/pulls/{n}causes GitHub to append a second, bare_Generated by [Claude Code](https://claude.ai/code)_block beneath the session-URL footer that was sent — even when the sent block is correctly formed with its rule line.The body content itself survives byte-for-byte; the extra footer is a pure suffix. It is caught only by the mandatory read-back.
Reproduced four times today, by three different agents on three cards
⇒ Not a one-off and not agent-specific. The initial
POSTthat creates a PR stores the footer once; only thePATCHpath doubles it.⭐ Why this is worth a line rather than a shrug
The workaround two rounds independently settled on was "never re-send the body" — leave the doubled footer rather than patch it again and risk a third. That is a reasonable local reflex and it is the wrong general rule: it makes agents avoid correcting a PR body, which is exactly the operation that fixes a wrong
Clause-②line, a stale census figure, or an inverted claim. Today one card needed three body rewrites to get its declaration right, and a "never re-send" habit would have argued against every one of them.The measured fix is the opposite of avoidance: send a body with no footer of its own and let the platform add exactly one, moving durable attribution (session URL and the like) into body prose where nothing dedupes it.
PATCH /issues/{n}(issue bodies) orPATCH /issues/comments/{id}. This seat edited both an issue body and a comment through REST today and read both back; ⛔ neither read-back was examined for this specific question at the time, so it is recorded as unknown rather than as a negative. Whoever writes the line should check, since the three paths are likely to differ.Dedup
Complete enumeration rather than a search zero: all 18 of 18 open
domain:skillscards listed and read; ⛔ none concerns footers, attribution, or RESTPATCHbehaviour. Control lit: 6 of the 18 carrypm-dispatchorskillsin the title. The listing was not truncated.search_issueswas not used and its result would not have been admissible: it returnstotal_count: 0withincomplete_results: falsefor terms that certainly exist, and REST/search/issuesis refused for repo-scoped sessions. Both measured today — see #16762.Refs #15275 (the platform-readings ceiling this increment would land against) · #16762 (the search channel) · PRs #17090, #17146, #17214.
🤖 Generated with Claude Code
https://claude.ai/code/session_01MkQhmuuJAVDjmeWNixwDDH