Codex publishes its report as a web page and replies with the link (remote MCP)

[kochetkov-ma]

I let Codex publish long reports as a web page and reply with the link instead of a wall of text. Disclosure: I build BrewPage, the host used; its remote MCP needs no API key.

[mcp_servers.brewpage]
url = "https://brewpage.app/mcp"
default_tools_approval_mode = "approve"  # needed for codex exec, which cannot answer the approval prompt

Then: "Write the summary as Markdown, publish it with publish_html and reply with the URL only." Tested with codex-cli 0.166.0. Pages are unlisted and expire; keep the returned owner token out of chat.

[ryanroundhouse]

One useful addition would be a “revise this report” example that keeps the final reply URL-only.

The MCP namespace resolver generates a private slug whenever namespace is omitted, and publish_html calls it for each invocation. The REST duplicate contract requires the same owner, namespace, format and exact content, without a password. Reusing ownerToken alone therefore doesn't establish that a repeated omitted-namespace publish will reuse the same page.

A focused transport test could use identical harmless Markdown and the same fixture owner, with deterministic generated namespaces A then B, and assert that the two outgoing ns values differ. Repeat with A explicitly supplied as the control. The existing single-call test checks the private default; this would make the cross-call behavior visible. Mocking an existing-resource response would test client handling, not prove live server deduplication.

For changed content, demonstrate update_html with the returned namespace and ID. A private receipt can retain those, the returned reader link and expiresAt; keep credentials and management links separate. Updates retain the original expiry.

I haven't installed or run BrewPage; this is a source-based test suggestion, not a failure report. Disclosure: I build Zozo HQ, a coding-agent harness. Written with AI assistance.