Turn any Code transcript into a public link at continuumcode.ai/share/<id>. The page is immutable, server-redacted, and safe to drop in Slack, iMessage, or X - without shipping your username or raw tool payloads.
The cloud doesn’t scrape your host history. Clients POST the transcript items they render; Continuum stores an immutable, redacted copy and returns a hard-to-guess link.
From Mac, iPhone, web, desktop, or the terminal client - any Code session transcript you can open.
See the redacted page before it goes public. Set expiry: 7 days, 30 days, or never.
Copy continuumcode.ai/share/<id>. SSR page with Open Graph tags; after load, no further network.
GUI clients mint with your account bearer. The host proxy path exists for the terminal client when there’s no cloud login.
Why not let the cloud fetch the transcript itself? Because it does not reliably have one. The live workspace mirror only carries sessions that were recently active on mirror-enabled hosts, and it is pruned on a retention window. Sharing last month’s debugging run that way would silently 404. So the client uploads the exact items it is rendering, the server writes its own immutable copy, and the link is good forever regardless of what the host does next.
Attribution follows the credential. A signed-in Mac, phone, browser, or desktop app mints against the cloud with your account, so the share belongs to the person who shared it. The host-minted route exists for exactly one caller - the terminal client, which has no cloud login - and a host that is signed out simply does not advertise the capability rather than half-failing. The shared transcript is capped at the same ceiling a host will ever publish, so a runaway session cannot mint a link nobody can load.
Redaction runs only on the server. Clients never “pre-clean” for trust - so no surface can widen what a link exposes. Messages are rebuilt from a known key set; unrecognized fields are dropped.
No username leak in the serialized payload. Tool detail / raw input is deliberately not stored - the UI never needed it, and it was the largest leak surface.
An allowlist fails in the safe direction. A field some host starts emitting next month is simply absent from shares until someone consciously adds it here. A denylist would ship it publicly on day one.
Dropping fields is only half of it. Every string that survives is scrubbed. Home directories collapse to ~ and temp paths to $TMPDIR, which is the invariant the whole feature leans on: no OS username survives a share, and it is asserted over the entire serialized payload rather than field by field. Email addresses and private-range IPs are masked. Public IPs are not, because they appear constantly in docs and URLs and redacting them would be noise rather than privacy.
Credential shapes are masked by pattern, not by hope: PEM private-key blocks, sk-ant- and sk- provider keys, GitHub tokens and fine-grained PATs, Slack tokens, AWS access key ids, Google API keys, JWTs, database connection strings that carry a password, plain API_KEY=… assignments, and dotenv lines caught in captured command output. Each becomes a labelled [redacted:…] marker, so the transcript still reads correctly. URLs lose their query and fragment, because that is where tokens ride. Control characters are stripped so terminal capture cannot smuggle escape sequences onto the page.
The preview tells you what it did: how many values were masked, how many paths were rewritten, and whether anything was truncated. You approve a redacted page, not a promise. If you have been pasting terminal output into chat threads to ask a colleague what went wrong, this is that habit with the obvious security problem taken out of it - and a good companion to the review habits you already apply to generated diffs.
The share page is rendered on the server, for one reason: per-share Open Graph tags. A static shell or a hash route cannot unfurl, and a link nobody can preview is a link nobody clicks.
The transcript ships inlined in the HTML as a JSON block. The page fetches nothing afterwards and runs under a policy that forbids outbound connections outright. No analytics beacon, no font CDN, no phone home.
Share ids are 22 random alphanumeric characters, roughly 131 bits, drawn by rejection sampling so no character is more likely than another. Enumeration is not a threat model, it is arithmetic.
No dashes or underscores in the id. Those get mangled by Slack and iMessage auto-linkers and by markdown emphasis, and a pure-alphanumeric id double-click-selects as a single token.
Shared pages carry noindex so they never enter a search index. What they deliberately do not carry is a robots.txt block on the share path: some social crawlers honour that file, and one line there would silently kill every unfurl on X. Unlisted comes from the id, not from asking crawlers nicely.
Choose 7 days, 30 days, or never when you publish. Revoke kills the link immediately. You can also update a share when you need a corrected snapshot without guessing a new URL.
Update re-uploads the transcript and re-applies the expiry, but it can never be pointed at a different session: the target is read from the stored row, not from whatever the client sends. A link you gave someone stays a link to the thing you gave them.
Revoked and expired are distinct states, and both are enforced when the page is read rather than by a cleanup job you have to trust. A revoked link stops resolving the moment you press the button. An expiry is a date on the row, so a 7-day link is dead on day eight whether or not anyone has looked at it. Nothing about a published copy is editable in place - “immutable” means a viewer and you are always looking at the same bytes.
Pick never for a link you want in a bug report or a design doc. Pick 7 days for the one you are dropping in a channel to ask a question. If a session went somewhere you would rather nobody re-read, revoking the share is the fast half; removing the local transcript is the other half.
Settings → Shared Links lists every share you own: title, expiry, and view counts. Open, copy, update, or revoke without hunting through old sessions.
The list is scoped to you. Reading it binds to your account at the database layer, so a share is visible to its owner and to anyone holding the link, and to nobody else. Anonymous viewers get a deliberately narrow read path with no account to bind to and nothing else it can reach.
View counts are the quiet signal that matters. A link with fourteen views is a link that traveled; a link with zero is one you can revoke without a conversation.
Publishing works from any transcript you can open: a Code session on the Mac, the same session on your phone, the web app on a borrowed laptop, the Windows or Linux desktop app, or the terminal client. It is the fastest honest answer to “what did the agent actually do?” - better than a screenshot of a scrollback, and better than pasting a wall of output into a channel where it will sit forever. It pairs naturally with writing the spec before the agent runs: the share is the receipt for whether the run matched it.
One surface is deliberately absent. watchOS never decodes a full transcript at all, so there is nothing there to publish. That is a real architectural boundary, not a roadmap gap. Everything else is covered, which is a different shape of answer from running Codex on its own, where the transcript never leaves the machine that produced it.
Short answers here, long answers in the docs.
No. Redaction is server-side only. Clients upload the items they render; Continuum rebuilds an allowlisted copy. There is no client “trust me, I cleaned it” path.
Not after load. The transcript is inlined in the SSR HTML (including OG tags for unfurls). The public page is designed for zero follow-up network under a tight CSP that blocks outbound connections outright.
No. Every share page is served noindex, nofollow, both as a header and in the markup. What it is not is blocked in robots.txt, because some social crawlers honour that file and blocking the path there would break link previews in X and Slack. The privacy comes from 131 bits of id entropy, not from a crawler’s cooperation.
You can update it, which re-uploads a fresh redacted copy to the same URL and re-applies the expiry. You cannot repoint an existing link at a different session - the target comes from the stored row, never from the request. If you want the old snapshot gone, revoke it and publish a new one.
Live mirror pages only cover recent, mirror-enabled host activity and are retention-pruned. Sharing an older session that way would silently 404. Publishing the items you’re already viewing is the reliable path.
No - deliberately. The watch never decodes full session transcripts, so there’s nothing to share from the wrist. Mac, iPhone, web, desktop, and terminal client can publish.
Open any Code transcript, preview the redacted page, pick an expiry, share.
server redaction · immutable · revocable