miinideckmiinideck
PricingUse casesBlog
Sign in
Sharing AI-built apps

Codex shared thread snapshots: what the link actually hands over

Codex can now share a thread as a read-only link. It shows someone how the work was reasoned — not the working thing it produced, and not a copy that keeps up with you. Here is exactly what the snapshot carries, the four boundaries the announcement doesn't spell out, and how to tell which of the two jobs you're actually doing.

By miinideck·September 2, 2026·7 min read

You finished something in Codex and now someone else has to see it. A colleague reviewing a pull request, a lead who wants to know why the approach changed, a client waiting on the thing itself.

Codex will give you a link. Whether that link is the right one depends on which of those two people you are talking to — because the link carries the conversation, not the build.

TL;DR
  • Thread sharing exists. OpenAI shipped shared thread snapshots on 20 August 2026, on all Codex plans, from the ChatGPT desktop app for macOS.
  • It hands over the reasoning, read-only: how the work was thought through, not a running copy of what it produced.
  • It is a snapshot. OpenAI's changelog says plainly that it doesn't update when the original thread changes. Send it, keep working, and the reader is looking at a frozen copy with nothing on the page to say so.
  • Personal-account links open for anyone holding the URL. Workspace links stay inside the workspace. Two very different privacy shapes behind one button.
  • Redaction is pattern-based. Known secret patterns are removed; OpenAI still tells you to review it. Things that aren't shaped like a key travel.
  • If the thing you owe someone is the build, this isn't the tool for it — that job wants something that runs, and usually something that survives your next revision.

What the snapshot actually contains

OpenAI's own framing is the clearest one: shared threads let you show the process behind your build with a read-only link — the context and reasoning behind a pull request, a deep dive, or a project handoff.

That is a real and slightly unusual thing to be able to send. Most sharing features hand over an output. This one hands over the derivation: what you asked, what Codex proposed, where you pushed back, which approach lost and why. For a reviewer trying to decide whether to trust a diff, that is often more useful than the diff.

It is worth being precise about the boundary, though, because the word "share" does a lot of work here and the two jobs pull in opposite directions:

A shared threadA handed-over build
What the reader getsThe conversation, read-onlySomething that runs in their browser
Should it change after you send it?No — a record that rewrites itself is a worse recordUsually yes — they should see your latest
What "done" looks likeThey understand the reasoningThey can use or judge the thing
Who it's forA reviewer, a teammate, your future selfA client, a stakeholder, a tester

Neither column is better. They are answers to different questions, and the friction people report almost always comes from using one where they needed the other.

Four boundaries the announcement doesn't spell out for you

None of these are faults. Each is a defensible design decision that becomes visible only in a specific situation — which is exactly the kind of thing worth knowing before you send the link rather than after.

1. The snapshot is frozen, and the page doesn't say so

OpenAI is explicit that the snapshot does not update when the original thread changes. For its stated purpose that is correct: a handoff record that quietly rewrote itself would be worthless as a record.

The trouble is a reader cannot tell. If you shared a thread on Monday, kept iterating through Wednesday, and someone opens the link on Thursday, they will read a coherent, complete-looking conversation that stops at Monday and draws conclusions from it. Nothing on their screen flags that. If the work is still moving, say so in the message that carries the link, because the link will not say it for you.

2. "Personal" and "workspace" are two different privacy models

Personal-account links can be opened by anyone with the link. Workspace-account links are limited to members of the originating workspace.

Same button, same visual result, materially different reach. The personal-account version behaves like a public URL that happens to be hard to guess: not restricted to the recipient, not tied to their identity, and as forwardable as any other link. That is fine when you meant to circulate something. It is worth a second's thought when you meant it for one person. We wrote about the same distinction showing up in what a Grok share link actually shares and in which Claude shares are public, and what unshare actually undoes — the specific behaviour differs per tool, but the question to ask is identical every time.

3. Redaction catches shapes, not meanings

Codex redacts known secret patterns, and OpenAI still tells you to review the shared content because sensitive content may remain. That instruction is doing real work.

Pattern-based redaction is good at things that look like credentials — a token with a recognisable prefix, a long high-entropy string. It has no opinion about an internal hostname, a client's name in a code comment, a paragraph where you explained why the previous vendor was fired, or a database URL you pasted mid-sentence while debugging. Threads accumulate that kind of thing precisely because they are working conversations, and a working conversation is a lot longer than the answer it eventually produced.

The practical habit: skim the shared view itself, not your memory of the thread.

4. It runs from one place

The changelog names the ChatGPT desktop app for macOS. If you are on Windows or Linux, or working from the web, thread sharing is not something you have misconfigured — it is not there for you today. Check OpenAI's changelog rather than a third-party page like this one for when that changes, since it is their feature and their schedule.

So which job are you actually doing?

The question that sorts it: does the other person need to understand it, or use it?

They need to understand it — a reviewer, a teammate picking up your branch, a lead asking why. Share the thread. The reasoning is the deliverable, frozen is correct, and nothing else you could send captures the "here's what we tried and rejected" part.

They need to use it — a client, a stakeholder, someone who is going to click around and tell you what's wrong. The thread will not help them. They need the build, running, in a browser, and they should not have to learn anything to open it.

For that second case the honest answer depends on what the build needs, and the best option is often not a link host at all:

  • It needs a backend, a database, or auth → deploy it properly. Vercel and Netlify exist for this and will do it better than anything that just serves files.
  • Everyone who will review it uses git → GitHub Pages. Free, permanent, and a real revision history, which is the one thing no file host gives you.
  • It's front-end only and it's for specific people → a private link works well: zip the folder Codex produced, get one URL, and replace the file as you revise so the link you already sent stays right. That is the shape we build for, and sharing a Codex build as a multi-file zip bundle walks through it, including what to check before you send it.

If the handoff is a whole Claude Code or Codex project rather than one page, where to put HTML an AI generated so someone else can open it compares the same options against the five things people actually ask for — assets that don't break, a stable URL, permissions, version history, and a reviewer who doesn't write code.

The short version

Codex thread sharing is a good feature aimed at a specific job: showing someone how you got there. It is read-only, it is frozen on purpose, its privacy depends on which account you're in, and its redaction is a first pass rather than a guarantee.

None of that makes it the wrong tool. It makes it a tool for the reviewer, not for the client. Once you can name which of those two you're sending to, the rest of the decision takes about five seconds.

Codex facts on this page checked against OpenAI's Codex changelog on 2 September 2026. OpenAI sets its own terms and ships often — check the changelog for what's current.

More in Sharing AI-built apps

Handing off a single-file prototype when you just need a decision

The prototype took an afternoon. Getting it in front of the person who has to say yes takes longer — because a repo-and-deploy is too much ceremony, an attachment opens as code, and a platform link drags your reader onto the platform. What the handoff actually needs.

September 20, 2026·6 min read

Sharing what an AI tool builds, before you deploy: the complete guide (2026)

From a Claude artifact to a vibe-coded app to a multi-file Codex bundle — how to share what an AI tool builds, as a private link, without a deploy pipeline.

August 21, 2026·3 min read

How to collect pinned feedback on a shared HTML page — and send it back to your AI (2026)

A step-by-step: turn on Review for a private link, let anyone pin comments to the exact spot (no account), then export the thread as a prompt to paste into Claude or Codex.

June 22, 2026·4 min read

Send your own private link.

miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.

Try it free →See pricing
miinideck

HTML files, finally as links — for AI builders, agencies, and consultants. Default-noindex, default-private, default-yours.

Product

  • Pricing
  • Use cases
  • Try it free

Resources

  • Blog
  • Free tools
  • Featured on
  • Report abuse

Legal

  • Privacy
  • Terms
Listed onmiinideck listed on Product Huntmiinideck listed on Faziermiinideck listed on TheSaaSDirmiinideck listed on AIToolHuntmiinideck listed on LaunchNest
© 2026 miinideckMade for people who don't want their work indexed.