What broke when I reviewed 5 agent-made HTML artifacts outside the agent session

Serren — Sat, 18 Jul 2026 15:58:33 +0000

I've been testing one narrow problem: Codex or Claude can make an HTML deck or report, but the person reviewing it usually isn't in the agent session.

I published five public artifacts and opened them as an outside reviewer. More of the runtime survived than I expected. Precise feedback was the part that got awkward.

Artifact	What survived	Review edge
FluidDocs single-file deck	12 slides, buttons, ArrowRight, exact text selection	Best result because the slides stay in one document
deck-transformer directory	15 relative slide pages, previews, play mode, next button, ArrowRight	Playback works, but text inside child iframes doesn't reach the outer feedback target
claude-code-transcripts	Index to page navigation, return link, `#msg-*` anchors	Cross-page review needs stable page and message IDs
claude-atlas report	Triage, Cytoscape graph, real diffs	Text is selectable inside the report, but the outer target still falls back to whole content
agent-review-panel	4 charts, 13 issue cards, P1 filter at 4/13, keyboard open, `#issue-AI-1`	Stable issue IDs help; iframe text selection still doesn't bridge

The shape that held up best

The cleanest result was a single entry document with slides or sections in the same DOM. The deck kept its own buttons and keyboard controls. The reviewer could still point at exact text.

Child iframes changed that. Navigation was fine. I could select the words in the child page, but the outer review surface only knew "whole content."

For agent-made decks, stable slide or issue IDs are worth keeping even if the layout changes. Something explicit like data-preapp-slide="pricing", or an existing anchor such as #issue-AI-1, gives the next agent run a better address than "the chart near the end."

Multi-page output is still usable. The transcript test kept relative links and #msg-* anchors. If comments need to survive v2, the page and message identity should survive regeneration too.

What comes back to the agent

I'm building PreApp around this return path. Feedback comes back with the source version, locator, and feedback ID. The agent relays it and waits for the owner to choose which IDs to apply. Reviewer text stays untrusted data.

None of these compatibility publishes count as external users, and I didn't submit feedback while testing them. They were just a way to separate "the HTML runs" from "a reviewer can point at the right thing."

I'm still looking for non-sensitive HTML or Markdown work made with Codex or Claude Code. The Codex first-publish page gives the agent three complete messages. Send step 1, reopen the agent once after install, then send steps 2 and 3.

If it stops before you get a view link, comment with the artifact type, OS, and failed step. Please don't post a token or private file content.

The CLI, Skill, MCP server, and protocol are in the MIT-licensed repo.

How I get reviewer comments back into Codex after sharing HTML

Serren — Fri, 17 Jul 2026 11:50:28 +0000

Putting a local HTML file online is mostly solved. There are small CLIs for it, plus the usual hosting platforms if you don't mind setting up a repo and a deploy.

The part that kept breaking for me came after I sent the link.

Someone would reply with a screenshot, or write something like "the total here is confusing." I still had to work out which version they saw, where "here" was, and how to turn that message into enough context for Codex to make a useful edit.

For a Markdown report, the same thing happened with page numbers and copied text. The file was easy to share. The feedback had lost its address.

I made a small CLI and Codex skill to test a different handoff. The basic flow looks like this:

Codex publishes -> reviewer comments in context -> Codex pulls the feedback -> I choose what to apply -> Codex publishes v2

Publishing from a Codex task

The easiest path now is to let Codex handle setup and publishing. Open the Codex first-publish page, sign in, and send the three complete messages on that page to Codex.

Send step 1 to install the CLI and Skill.
When installation finishes, reopen the Codex task once so it discovers the Skill.
Send steps 2 and 3 from the same page. The access token stays inside the Agent message; don't paste it into a comment, screenshot, or issue.

The last message asks Codex to find the HTML or Markdown deliverable in the current task, publish its local assets, verify the view link, and return separate view and feedback links. I don't have to identify the file path or assemble CLI flags first.

The reviewer doesn't need an account. They can select text, click an image or diagram, or leave a note on the whole document.

The separate links ended up mattering more than I expected. I can send a clean reading link to someone who only needs the report, and a feedback link to the person doing the review.

Pulling comments back into Codex

After the review, Codex can run:

preapp feedback get checkout-review --format markdown

The result includes a feedback ID, source version, and locator for each item. A text comment carries the selected quote and its surrounding context. Image and diagram comments carry their target reference. Markdown feedback also maps back to the source file and line.

Publishing the same slug creates v2 while the shared link stays the same. Old comments stay attached to the version they were written against.

I deliberately didn't make the skill auto-apply everything it reads. Reviewer text is untrusted data. Codex first relays the feedback, then stops. I choose the feedback IDs it may use before it edits anything.

That sounds a little fussy until someone writes a comment that looks like an instruction to the agent. In the production test, I included one of those on purpose. It stayed in the source feedback and never became a change instruction.

Interactive HTML needs a little more context

The Agent-first message handles static reports. For an HTML prototype with buttons, routes, or client-side state, I can still publish it with a review profile:

preapp publish ./dist \
  --slug checkout-review \
  --review-profile prototype \
  --format json

The reviewer can use the page normally, switch into feedback mode, and click the exact element they mean. The locator includes the page hash, viewport, scroll position, element rectangle, and optional data-preapp-* labels from the source.

The owner can then turn selected feedback into a revision brief. Codex reads that brief instead of treating every raw comment as an edit request:

preapp revision get checkout-review --version 1 --format markdown

What the first real run caught

I ran the full flow on a checkout prototype in production. It went through four versions, two review loops, six feedback items, and two applied revision briefs.

The useful part wasn't the count. One reviewer caught a missing loading state on the submit button. Another asked for the total amount and item count to stay visible. A later review found that the total didn't say whether shipping was included.

There was also a real bug in the review interface itself: after rewriting or merging an item, focus moved to a hidden pane. Dogfooding the feedback loop exposed that too.

The same share link kept working through v1 to v4, while each comment stayed on the version and HTML state where it was made.

I recorded the full loop in a 41-second demo.

The first outside test

Someone I hadn't worked with before tried the same flow on a synthetic weekly quality report. The reviewer flagged a recommendation that converted an empty unit_price string to null, since that could hide a broken vendor contract.

The Agent pulled the note with the selected text and source version. About three minutes later, the creator published v2: the coercion was gone, the report now called for boundary validation and quarantine, and it added a vendor-specific E_EMPTY_UNIT_PRICE error.

This was the first run where the person publishing the artifact wasn't me. They kept control of the edit, and the reviewer never needed the source file or Agent token.

Trying it on real work

The CLI, Codex skill, MCP server, protocol docs, and examples are in an MIT-licensed repo:

https://github.com/serrendypity/preapp-agent

The hosted share and review service is PreApp. That part isn't open source, and it's free during early access.

I'm looking for 10 people who already use Codex, Claude Code, or another shell-capable agent for reports, HTML presentations, or prototypes. The useful test is one real, non-sensitive HTML or Markdown artifact, not a canned example. I'll help with the first publish if the setup gets in the way.

If you have one, open the Codex first-publish page above and send the three messages to your Agent. If anything stops before you get a view link, reply with the artifact type, OS, and the step that failed. Don't post a token or private file content.

DEV Community: Serren