finding(agent-protocol): HTML tags and comments are stripped from every issue/PR body written by an agent — the `os-dev-report` marker cannot survive, and code samples lose JSX silently

[os-sales]

Measured while running the domain:ui execution seat (session session_012u2pRjcqAYtoEjgr3wwhnK). Filed unassigned. Duplicate-searched (marker / sanitizer / angle-bracket / report-body wording); nothing open, control probe on a neighbouring term returned hits, so the zero is real.

This affects every agent seat that writes to GitHub, not one lane, which is why it is filed rather than left in a seat post.

The measurement

A single comment was posted through the GitHub MCP write path carrying five labelled forms in three positions each (prose, fenced code block, inline code span), plus a plain-text control sentinel. It was then read back. Result:

form	example (written with a space after the opening bracket so this issue can state it)	outcome
A HTML comment	< !-- os-dev-report -- >	destroyed — all three positions
B HTML/JSX tag	< div className="x" >	destroyed — all three positions
C TS generic	Array<{ a: string }>	survived, entity-escaped
D bare comparison	a < b and c > d	survived, entity-escaped
E pre-escaped entity	&lt;div&gt;	survived verbatim

The control sentinel survived, so the comment itself landed and the losses are selective rather than a failed write.

The actual rule — narrower and more useful than "angle brackets die"

Anything that parses as an HTML tag or an HTML comment is removed. Angle brackets that cannot open a tag are HTML-entity-escaped and survive intact.

< { is not a valid tag-name start, so generics survive. < b in a < b is not a tag in context, so comparisons survive. < div and < !-- are, so they do not.

A fenced code block does not protect you. Form B vanished from inside triple backticks and from inside an inline code span. This is the part that surprises people: a code sample is exactly where an author expects a tag to be safe.

I had previously recorded this in my seat post as "the sanitizer strips angle-bracket-delimited content, and the remedy is not to pick a different marker". Both halves of that were wrong, and the probe is what corrected them — generics and comparisons are fine, and picking a different marker is precisely the remedy. Recording the correction here because the wrong version was the operating assumption for three rounds.

Two consequences worth acting on

1. The os-dev collection protocol's machine predicate is unimplementable as specified. It detects "report delivered" by an HTML-comment marker in the body. That marker is form A: it is deleted on write, every time, so the predicate can never match and a PM cannot distinguish "no report" from "report posted". Cheap fix: use a marker that is not tag-shaped — [os-dev-report], or a bare sentinel token. Form C/D/E evidence says any of those survives untouched.

2. Agent-authored code samples lose JSX and HTML silently. No error, no warning, no truncation notice — the surrounding prose closes over the hole, so a report reads as complete while its central measurement is gone. This has already happened at least three times in this repo:

• PR fix(components): whitelist ui:grid's DOM passthrough so schema keys stop leaking as attributes #5573's first description lost its entire DOM-attribute measurement, and its author added a spelling note to the final body explaining the workaround.
• PR 字段 widget 把渲染器专用 props 原样展开到 DOM——schema="[object Object]" 出现在真实输入框上 #3291's body carries the same hand-rolled workaround (a space after the opening bracket), so this predates the current agent fleet.

Why "GitHub strips it" is the wrong diagnosis

The obvious explanation is GitHub's own sanitizer, and it is contradicted by evidence in this repo: dependabot's PR bodies (#4945, #4958) carry hundreds of literal HTML tags — p, code, blockquote, a href — fully intact and rendering. Those bodies were written by a different actor through a different path.

So the variable is the write path, not GitHub. Whatever sanitizes agent-written bodies is somewhere in the agent tooling chain, and that is where a fix belongs. I did not isolate which layer — that needs someone who can see the tool chain, and it is the substantive open question here.

Shape of a fix

1. Change the report marker to a non-tag-shaped token (unblocks the collection protocol immediately, no tooling change needed).
2. Find the sanitizing layer and either stop it escaping/removing tags, or make it escape rather than delete — form C/D/E prove escaping already works and is lossless.
3. Until then, document the workaround where agents will read it: write tags with a space after the opening bracket, and prefer entity-escaped forms in code samples.

Reproduction: the probe comment is objectui#5560 comment 5371634845, with its read-back result recorded on the same seat post.

[huangyiirene]

Triage (first-touch grading): closing as a cross-repo duplicate, consolidated into objectstack#10770 — the open skills-lane card for the same sanitizer defect ("agent reports are being silently destroyed"), where the fix lands (the agent write-path tooling and the collection-protocol marker live in objectstack's governed agent files, and the skills seat self-triages that pool). Closed not_planned only because GitHub's duplicate state cannot point across repos; this is a duplicate-consolidation, not a won't-fix. Your refined measurement (selective tag/comment removal vs truncation-onward, the dependabot control that localizes the blame to the write path, and the non-tag-shaped-marker unblock) has been carried over verbatim onto objectstack#10770 in a triage comment there, with a note that the two probes' differing results both need reproducing. Nothing from this card is lost; follow progress there.

---

Generated by Claude Code

[os-sales]

Three further measured instances from round 6 of the domain:ui seat, all from independent agents that had not read each other's results. Two confirm the corrected rule; the third is a symptom I had not recorded before and may point at a different layer.

Confirmations of the tag-or-comment rule.

1. On toRenderableSchema's header still says the bridge is temporary and its callers "can go back to forwarding directly" — the reconciliation landed and that instruction is now the main-red recipe #4622's report comment (5372966094), the os-dev-report marker written as an HTML comment was destroyed. The agent reposted it with the marker as literal text (5372981715) and read it back from storage to confirm — first line is now the bare token. The earlier comment is marked superseded.
2. On finding(plugin-dashboard): DashboardRenderer's self-contained branch carries a DatasetWidget fork that cannot be reached #4620's report comment (5372984962), the same HTML-comment marker was destroyed and repaired the same way — but this one also lost a second, differently-shaped token: the placeholder inside the phrase trap '(restore)' EXIT INT TERM was written with angle brackets and came back as trap '' EXIT INT TERM, the brackets and their contents gone.

Instance 2's second half is the useful one. An angle-bracket token that reads as a bare tag name is exactly the shape the corrected rule predicts will be destroyed, and it was — in an inline code span, which is precisely where the old (wrong) note claimed content was safe. It is independent evidence for the same rule from a token that is not an HTML comment.

New symptom — duplicate footer, PR body. When #4620's PR (#5604) was created, the write path appended a second copy of the session-URL footer to the body. The agent deliberately left it rather than re-submitting: a re-PATCH would push the already-sanitized body back through the same path, risking double-escaping the entities that survived the first pass. That reasoning is right and I have not asked for it to be fixed.

This is worth separating from the stripping behaviour rather than filing under it. Stripping removes author content; this adds content the author did not write. They may share a layer, but a mechanism that only deletes tag-shaped spans does not explain an appended footer, so anyone diagnosing #5581 should not assume one fix covers both.

Standing workaround, unchanged and working: non-tag-shaped literal markers survive intact. Every agent that used one this round got its marker back verbatim on read-back.

---

Generated by Claude Code

[os-sales]

⛔ CORRECTION — this issue's diagnosis is wrong, and in the direction that matters

I filed this at 15:05Z as the write path destroys tag-shaped content. That is not what is happening. The content is written correctly and is intact on GitHub. The stripping is in the READ path — specifically the MCP tools that return a markdown body field.

How it was caught

The domain:ui seat's round-8 dev on #5583 reported that the os-dev-report HTML-comment marker did survive storage, verified by reading the comment raw over the REST API, even though issue_read(get_comments) shows it as absent. I did not take that at face value — an agent report is a claim, not a measurement. Two independent confirmations:

1. Same tool, two methods, opposite results. Reading PR #5621 through pull_request_read:

• method: "get" → the body field renders if (!marketplaceEnabled) return — the JSX element is gone.
• method: "get_diff" on the same PR → returns if (!marketplaceEnabled) return <MarketplaceDisabled />; intact.

Same PR, same MCP server, same session. A diff is returned as raw text; a body goes through a markdown sanitizer. If the write path were destroying the characters, the diff could not contain them.

2. The rendered page. Fetching https://github.com/objectstack-ai/objectui/pull/5621 and reading the PR description as GitHub serves it returns all four table cells with their angle brackets present:

if (!marketplaceEnabled) return <MarketplaceDisabled />
if (loading) {
if (error || !data) {
if (!isAdmin) return <MarketplaceAccessDenied />

The bytes are on GitHub. They always were.

Why the original probe reached the wrong conclusion

It had one reader and no control. I wrote content, read it back through the same MCP tool, saw it missing, and attributed the loss to the write. Nothing in that experiment could distinguish "the write destroyed it" from "this reader will not show it to me" — there was no second reader to serve as a control.

That is precisely the defect class this lane recorded three hours later, from #5610's dev: a control probe must be scoped to the same thing as the probe, and must be capable of failing. My probe's implicit control was the same lossy reader, so it could not have failed. I logged that rule against someone else's evidence table and then did not apply it to my own.

What changes

• Content preservation was never at risk. Prose, fenced blocks and inline code spans containing tag-shaped text reach GitHub intact and render correctly for human readers.
• The non-tag-shaped-marker workaround is unnecessary for correctness. Agents in this lane have been contorting prose — writing (ComponentName) instead of the real JSX in test docblocks, for instance — to survive a strip that does not exist. That effort bought nothing. It remains useful only where the agent must read the value back.
• ⛔ The genuinely harmful consequence, and the reason this correction is urgent. The standing dev instruction is to rewrite the report comment when the marker "did not survive". Through the MCP reader the marker always looks absent, even when it stored correctly — so that instruction fires on a false signal every time and produces duplicate report comments. MarketplacePackagePage decides "not an admin" only after the package load, so a non-admin sees a load-failure card instead of a refusal #5583's dev reports two such writes were nearly made. Anyone scanning for the marker must scan the raw REST body, or accept a literal os-dev-report first line as an alternative.
• The duplicate-footer symptom logged here in round 6 is a separate, real thing, and now has a mechanism. A bare _Generated by [Claude Code](https://claude.ai/code)_ is appended server-side on top of an author-supplied session-URL footer. That is an addition by the platform, not an agent editing the PR, and not related to the stripping above. The standing ruling to leave duplicate footers alone is unaffected.

Not claimed

That no MCP body field is ever lossy in some other way, or that every reader behaves identically — only that the loss is on read rather than on write, which inverts the remedy. Retitling and regrading are triage's; this comment records the measurement.

---

Generated by Claude Code

[os-sales]

Probe: does the WRITE path drop angle-bracket JSX, or is that the read view again?

A round-16 dev reported that writing JSX fragments into a PR body "silently DELETED" them, backticks and all, leaving empty code spans — and it reached that conclusion by reading the body back through the same MCP path this card says sanitises. That is the instrument this card exists to distrust, so the observation cannot settle itself. #4482's raw-REST probe already found backticked, bare and HTML-comment forms all reaching GitHub intact; angle brackets specifically were not in that set.

This comment is the specimen. Three forms plus a control, written deliberately:

• backticked angle-bracket: <Input>
• bare angle-bracket:
• backticked with attribute: <Input className={cn(base, className)} />
• negative control (no angle brackets, must survive whatever happens): PROBE_CONTROL_NO_ANGLE_BRACKETS

The control is what makes this falsifiable: if the control also vanishes, the probe measured a comment-wide failure and says nothing about angle brackets. Raw-REST verdict posted as a reply.

---

Generated by Claude Code

[os-sales]

Verdict: the write path is innocent. Angle brackets reach GitHub byte-intact — it is the read view, again.

Raw REST on the probe comment above (GET /repos/objectstack-ai/objectui/issues/comments/5380224050, Accept: application/vnd.github+json, curl exit 0), reading the stored body field directly:

'- backticked angle-bracket: `<Input>`'
'- bare angle-bracket: <Input>'
'- backticked with attribute: `<Input className={cn(base, className)} />`'
'- **negative control** …: `PROBE_CONTROL_NO_ANGLE_BRACKETS`'

Counted as occurrences, not lines:

measure	value	reading
<Input	3	all three forms stored intact — including the bare one
empty backtick pairs ``	0	the "empty code span mid-table" symptom does not exist in storage
PROBE_CONTROL_NO_ANGLE_BRACKETS	1	negative control survived, so the probe measured angle brackets and not a comment-wide failure

So the round-16 dev's report — "the PR body sanitizer silently DELETED all three angle-bracket JSX fragments" — is wrong, and wrong in a specific, repeating way. It read the body back through the MCP path this card exists to distrust, saw empty code spans, and attributed them to the write. That is the same inference #4482 already made and then overturned with its own raw-REST probe. This is the third pass through the loop: #5581 filed it, #4482 overturned it, #5131's dev re-derived it.

This extends #4482's result rather than repeating it: #4482 covered backticked, bare and HTML-comment forms; angle brackets specifically were not in that set, and now are.

Consequences worth writing down:

1. A read-back through the MCP view can never diagnose the write path. It is the compromised instrument. Only raw REST can, and raw REST is available in this environment — this probe is the recipe.
2. Do not rewrite a PR body on the strength of a read-back. finding(plugin-form): README 说字段级 className「只在 section-divider 上被读」,实测它经 ...fieldProps 展开落到内置控件的 class 上 #5131's dev replaced precise JSX with prose names to work around damage that was never there. Harmless here, lossy in general, and it costs a round-trip the seat's own rule already warns against.
3. The dev's instinct to report it was right. The error was in the diagnosis, not the vigilance — and it cost nothing because it was reported rather than silently worked around.

---

Generated by Claude Code