Claude’s private-by-default chat history was not breached. The affected material was a narrower class: snapshots that users explicitly made public, then exposed to discovery when their links appeared somewhere a crawler could reach. Search indexing made those already-public snapshots substantially easier to find. It did not turn every Claude conversation into a public page.
Incident scope at a glance
- Risk level: High
- Evidence level: High
- Affected: Public chat snapshots whose unguessable links were posted on crawlable pages, plus any secrets or personal data visible in those snapshots
- Not affected by this incident: Chats that were never shared; messages added after a snapshot was created; attached files themselves; raw MCP tool-call data; organization-restricted Team and Enterprise sharing
- Current status: Google results had disappeared by named reporting on July 27–28. That is a remediation signal, not proof that Bing results, cached references, screenshots, or third-party copies disappeared.
- Scale: Unresolved. Contemporary reports observed searchable results and sensitive categories, but no reliable total for the July 2026 event has been independently established.
Anthropic’s sharing documentation says chats are private by default. Creating a public link produces a snapshot containing every message sent before sharing, including artifacts. Later messages stay private unless the user unshares and shares again. Attached files and raw MCP tool-call data are excluded, although conversation text and Claude’s final responses remain visible. Free, Pro, and Max users can inventory snapshots under Settings → Privacy → Shared chats; Team and Enterprise sharing is restricted to the organization.
This is a technical incident-response guide, not legal advice.
Timeline: July 25–28, 2026
| Date | What was established |
|---|---|
| July 25 | A Reddit user flagged that a site: query could surface Claude share URLs. This is the discovery date reported by TechCrunch, not an AIHackers reproduction. |
| July 27 | TechCrunch and WIRED reported searchable public snapshots. TechCrunch attributed reports of medical, child-contact, company-internal, employee, code, and work-note material to named outlets; AIHackers did not inspect those chats. |
| July 27 | TechCrunch’s afternoon Google check returned no results. WIRED reported that its Google query no longer returned results while Bing still did at publication time. |
| July 28 | WIRED added Anthropic’s response: the company said it did not submit share directories or sitemaps and that a share link became discoverable only after someone posted it where a crawler could see it. |
Do not use the screenshot to estimate how many snapshots existed or remain indexed. It records no capture date, exposes no conversation content, and does not establish present search behavior.
Evidence matrix
| Evidence class | What it supports | What it does not support |
|---|---|---|
| Anthropic documentation | Private-by-default history; explicit snapshot creation; included and excluded snapshot data; organization-only sharing; inventory and unshare controls | Search-engine behavior, number of indexed pages, or erasure of third-party copies |
| Independent reporting | Google and Bing discovery in July; examples of sensitive-content categories; Google-result disappearance during reporting; Anthropic and Google responses | A complete inventory, a stable affected count, or proof that every copy disappeared |
| AIHackers checks | The reader screenshot demonstrates prior discoverability. On August 24 at 15:21 SGT, one nonexistent all-zero share UUID returned 200 text/html and the literal header X-Robots-Tag: none to normal, Googlebot, and Bingbot user agents; the live robots.txt did not disallow /share/. | Behavior of any real snapshot, historical headers, current search results, caches, archives, or universal remediation |
| Unresolved | The July event’s total scale, how many links were posted publicly, which engines or archives retained references, and whether any third party copied content | Any precise affected-count claim |
The evidence level is high because primary product documentation, two named independent reports, a supplied screenshot, and a reproducible route-level check agree on the mechanism. High evidence does not turn unresolved scale into a number.
How a private chat became a searchable public snapshot
The exposure chain required several distinct steps:
- Explicit share action: A user selected Share and created a public snapshot.
- Anonymous public access: Anyone holding the unguessable URL could view the snapshot without joining the owner’s account.
- Crawlable publication: Someone posted that URL on a forum, social post, public document, or other page a crawler could reach.
- Discovery or copying: A search engine indexed the URL, or a third-party service archived or copied it.
“Unguessable” is an access property, not a confidentiality guarantee. Once a bearer URL is pasted into a public page, referral trail, issue, or searchable document, normal web discovery can make it easy to find.
Why robots.txt and noindex can conflict
robots.txt controls crawler access; a page-level noindex directive controls whether a fetched page should appear in results. They are not interchangeable.
Google’s documentation explicitly warns that robots meta tags and X-Robots-Tag headers are discovered only when a URL is crawled. If robots.txt blocks that fetch, the crawler cannot see the page’s noindex instruction. Bing documents its supported robots meta tags and attributes, while WIRED reported that Bing recommended page-level noindex in addition to crawl controls.
That tension explains why a crawl block is not evidence of non-indexing, and why the August 24 all-zero response is only a point-in-time route check. Its literal X-Robots-Tag: none is not a noindex directive. It also says nothing about what a valid existing snapshot returned before or after that check.
What to do now
1. Inventory and unshare every sensitive snapshot
Open Settings → Privacy → Shared chats, review the title, sharing date, and link for every entry, then select Unshare for anything that should not remain public. Anthropic says this changes the snapshot from Public to Private and disables the direct link.
Record the sharing time, unshare time, affected systems, and response owner in your private incident log. Do not paste exposed material into a public ticket.
2. Revoke secrets before chasing search results
Treat every credential visible in a public snapshot as compromised. GitHub’s secret-remediation guidance prioritizes immediate revocation for active public or production secrets.
- Revoke or rotate the secret at its issuer.
- Replace it in every application, workflow, device, and dependency that used it.
- Terminate sessions or tokens derived from it.
- Audit activity from the original sharing time onward.
- Only then remove stale copies and references.
Deleting a chat, unsharing a snapshot, or deindexing a result does not make an exposed credential safe again.
3. Replace keys and wallets, not just strings
Handle SSH and signing-key exposure as a new-keypair event: generate a fresh pair, deploy the new public key, remove trust for the old key everywhere, revoke certificates where applicable, and review signed or authenticated activity.
If a cryptocurrency seed phrase or private key appeared, create a new wallet from uncompromised material and move assets. Removing the page cannot restore secrecy to the old key.
4. Escalate regulated or organizational data
Personal, medical, customer, employee, child, legal, or company-confidential data belongs in the organization’s security and privacy process. Preserve a minimal private timeline, notify the responsible incident lead or data-protection contact, and follow contractual or regulatory procedures. Do not contact people named in reporting or copy their exposed data into a new system.
5. Request search removal after source revocation
After unsharing and rotating secrets, request a stale-result refresh or qualifying personal-information removal through Google. Microsoft provides routes to remove cached pages or request Bing content removal.
Search removal affects a search surface, not the rest of the internet. Google explicitly warns that removed results can remain reachable through direct links, social media, or other engines. Neither request erases screenshots, private archives, downloads, or third-party copies.
How to prevent a repeat
- Treat every public share link as publication. “Anyone with the link” is not a private audience once the link leaves a controlled channel.
- Create a new redacted transcript for sharing. Do not publish the working chat and hope reviewers notice its earlier context.
- Scan before sharing. Check prompts, outputs, code, terminal logs, artifacts, names, contact details, customer data, credentials, private URLs, and system identifiers.
- Prefer organization-restricted sharing. Use a managed Team or Enterprise boundary when recipients belong to the same organization and its controls fit the data.
- Make policy explicit. Prohibit public sharing of sensitive chats in team rules, code-review checklists, and agent instructions. The repository’s AGENTS.md secret-handling rules are one concrete pattern.
- Test revocation. A control is incomplete if owners cannot inventory and disable links quickly during an incident.
The same publication rule applies outside Claude. OpenCode session sharing also creates a public link and moves conversation history to a hosted service.
Five controls that must stay separate
Retention, deletion, training, public-link access, and search indexing answer different questions:
| Control | Question |
|---|---|
| Retention | How long does a provider or connected system keep data? |
| Deletion | What copy is removed, on what schedule, and with which exceptions? |
| Training | May the provider use content to improve models? |
| Public-link access | Can someone holding a URL retrieve a snapshot? |
| Search indexing | Can a search engine make that URL easy to discover? |
Turning off training does not revoke a public link. Deleting account history does not rotate a leaked key. Removing a search result does not erase a third-party copy. The Claude vs OpenAI retention explainer maps the adjacent storage and deletion controls.
What local models remove—and what they do not
A local model removes this specific provider-hosted share-link path only when the complete workflow stays local: inference, UI, history, RAG or vector storage, telemetry, backups, and tools. A local runtime with a cloud-synced UI, remote MCP server, hosted search tool, shared GPU service, or off-device backup still crosses another data boundary.
Use the Local LLM guide to choose that lane for the right reason. “Local inference” alone is not a blanket privacy guarantee.
Sources and archive status
- Anthropic: Share and unshare chats (Archive)
- Anthropic: Consumer Terms of Service (Archive)
- WIRED: Private Claude Chats Exposed in Google and Bing Search Results (Archive)
- TechCrunch: PSA: Your Claude shared chats and Artifacts may have ended up on Google (Archive)
- Google Search Central: Robots meta tags specifications (Archive)
- Bing Webmaster Tools: Supported robots meta tags and attributes (Archive)
- GitHub: Remediating a leaked secret (Archive)
- Google Search Help: Remove private information or refresh stale results (Archive)
- Microsoft Support: How Bing delivers search results (Archive)
Archive status: all nine listed captures replayed as 200 text/html on August 20, 2026. The August 24 route check did not fetch or archive any real shared chat.
Related guidance
- Claude terms overview
- Risk level rubric
- Claude vs OpenAI data retention
- Running LLMs locally
- OpenCode sharing and privacy
- Risks index
Last checked August 24, 2026. Search results, response headers, sharing controls, and provider documentation can change independently.