Read Claude Web Conversation

Read Claude.ai Web Conversation

Pull a Claude.ai web conversation into a full, structured transcript — every message and every tool call, not just what is currently on screen.

Verified against Claude.ai's web API as of July 2026. These are the same private JSON endpoints the Claude.ai front-end calls; they are not a documented or version-stable public API, so if a request 404s, re-derive the shape from the Network tab (see references/claude-web-api-extraction.md).

This skill vs. its siblings

Pick by the source you are holding, not by the word "conversation":

Why the obvious approaches fail (read this first)

Four traps, and every one of them fails silently — you get back something that looks like a complete export, and you only notice the loss if you happen to know how long the conversation really was. Assume you are being lied to by default; the fidelity gate in Step 4 exists to make the lies audible.

1. Login wall. curl and WebFetch don't get an auth redirect — they get a Cloudflare challenge page (HTTP 403, Just a moment...). Nothing you do to the headers fixes this; the page is gated on a session that lives in the user's Chrome. Never reach for curl here, not even to "just check".
2. Virtual scrolling. With the conversation open, get_page_text and DOM scraping still only see the handful of messages currently rendered — often just the last one. A 40-message thread comes back as 1.
3. Default rendering collapses the tool calls. The API's default rendering turns every tool call into a "not supported on your current device" placeholder. On a research/agent conversation the tool blocks ARE the content: measured on a real one, the default rendering returned 9.4k chars against 173k with render_all_tools=true — 5%. Always request the full rendering.
4. A /chat/-shaped renderer silently drops /share/ blocks. A share payload returns web_search hits as knowledge items, not text items. A renderer that only knows text returns the empty string for them and reports no error — the same real conversation rendered to 8k chars instead of 146k (4.8% retention) and looked completely fine.

The reliable path: run JavaScript inside the user's logged-in page and let fetch inherit the session cookie, then render locally through the fidelity gate.

Step 0 — Choose an injection channel

Three channels can execute JS inside the user's page. They differ only in plumbing, and each fails in its own way, so pick in this order and verify rather than assume.

⚠️ Expect CDP to be unavailable, and never try to force it. Since Chrome 136 (April 2025) the debugging port is ignored on the default user-data-dir — a deliberate hardening against malware that used CDP to steal cookies. You may still find a listening socket and a stale DevToolsActivePort on disk while the WebSocket handshake is never answered and /json/* returns 404.

And its availability flaps. Verified on Chrome 150, one machine, one browser session: the endpoint worked, then stopped answering entirely, then answered again — with no restart in between. So probe every time and never cache the verdict. "CDP worked five minutes ago" is not evidence that it works now, and "CDP failed once" is not evidence that this machine can't use it. The probe is cheap precisely so you can afford to re-ask.

The trap is what you'll be tempted to do next. Every fix on the web says "relaunch Chrome with --user-data-dir=/tmp/whatever". For this skill that is worse than useless: a fresh profile is signed out, and a signed-out browser cannot read a single one of the user's conversations. The session you need lives in precisely the profile Chrome is refusing to expose. So probe, take the answer, and fall back — never reconfigure or relaunch the user's browser to chase a port.

CDP does work when Chrome was deliberately started on a non-default --user-data-dir and is signed into claude.ai. That happens, and when it does this channel beats the others outright (no menu toggle, immune to the Apple Events capture below, enumerates every tab, returns the whole payload on stdout). That is why it is worth one cheap probe before falling through.

To try channel 1, load the extension's tools in a single ToolSearch call (they are deferred; the API path needs no get_page_text / read_page):

ToolSearch: select:mcp__claude-in-chrome__tabs_context_mcp,mcp__claude-in-chrome__navigate,mcp__claude-in-chrome__javascript_tool

then call list_connected_browsers. An empty list is the account mismatch — go to channel 2 rather than retrying.

To try channel 2:

uv run --with websockets python scripts/cdp_channel.py probe

probe answers three questions at once: is CDP available, is it pointed at the user's real browser (page count, and any claude.ai tabs already open), and are there multiple Chrome instances running. Its output drives everything below — including the AppleScript decision, since the chrome_instances.automation list is what tells you whether Apple Events will even reach the right browser.

Exit codes are a contract, so you never have to guess whether to fall back:

Exit 3 still prints chrome_instances, because that part needs no debugging port. It is a routing fact, not an error: read it, fall through to channel 3, and say nothing to the user about debugging ports.

The AppleScript routing trap (read before you blame the user)

AppleScript addresses Chrome by bundle id. If a second Chrome instance is running — chrome-devtools-mcp, puppeteer, playwright, anything launched with its own --user-data-dir — Apple Events can land on that instance instead, and macOS gives you no way to target the first one by pid. There is no workaround.

What makes this genuinely dangerous is how it presents: the automation profile has "Allow JavaScript from Apple Events" switched off, so your JS attempt fails with "Executing JavaScript through AppleScript is turned off" — and you will conclude the user forgot a menu toggle, and go ask them to flip it, while their real browser had it enabled the whole time. Observed exactly this: AppleScript reported windows=1 tabs=1 while the user's actual Chrome had 35 tabs open.

So before falling back to AppleScript, run probe (or chrome_instances() from cdp_channel.py) and read the automation list. If it is non-empty, say so plainly — "an automation Chrome is holding the Apple Events route, so AppleScript will hit the wrong browser" — and either use CDP, or ask whether that instance can be closed. Do not relay a toggle error you cannot attribute.

Channel details and the base64 binary bridge: references/applescript_fallback_channel.md.

Step 1 — Identify the account case (this decides what you can even get)

How much of the conversation exists for you to fetch depends on whose account the browser is signed into. Establish this early — it is the difference between a complete archive and one with unrecoverable holes, and the user deserves to know which they are getting before you hand it over.

For a /share/… link, the snapshot payload itself tells you which case you're in: it carries conversation_uuid (the original) and creator. So fetch the snapshot first, then try the original with that conversation_uuid — if it 200s you are in case B and should re-export from there, because the snapshot is strictly lossier. If it 404s, you are in case C: say so out loud, and let the render step disclose the gaps in the transcript header (it does this on its own).

Case C's holes are real and worth naming precisely, because they look like a bug in your export when they are not: a view of an uploaded file keeps its name but loses its path and the file's entire content. The user's own copy of that file is usually sitting on their disk — the export isn't broken, it just cannot speak for a file the platform declined to share.

Step 2 — Open the conversation

Extension: tabs_context_mcp with { "createIfEmpty": true }, then navigate. CDP: cdp_channel.py open --url <url> (reuses an existing tab; waits out the Cloudflare interstitial, which the browser clears by itself).

Either way, confirm it actually loaded and is logged in — the tab title should be the conversation's name, not "Log in". If you land on a login page, stop and tell the user; do not automate a login.

Step 3 — Fetch the payload

Always request the full tool rendering. Without render_all_tools=true you get placeholders where the analysis was (trap 3 above).

Note the share endpoint keys on the snapshot id from the URL, which is not the conversation id — feeding a snapshot id to chat_conversations 404s, and that 404 means "wrong id", not "you lack access". Both id families are opaque; always derive them from the open URL rather than hard-coding.

• Extension channel → run scripts/export_conversation.js in the page (fire-and-poll instructions are in its header), then page out window.__claudeExport.rawJson in ~16k .slice() windows.
• CDP channel → run scripts/fetch_cdp.js, which returns the full conversation JSON directly as a Promise, so cdp_channel.py eval resolves it in one call and streams the result to a file:

  uv run --with websockets python scripts/cdp_channel.py eval \
      --match <conversation-or-snapshot-id> --js scripts/fetch_cdp.js --out conversation.json

  awaitPromise resolves the async fetch in one call, and the value comes back on stdout, so a multi-megabyte payload never has to cross a context window.
• AppleScript channel → run scripts/export_conversation.js via scripts/runjs.applescript, then poll and read out window.__claudeExport.rawJson (fire-and-poll; see the channel reference).

For a plain chat with no tool calls, where you just need the text right now, the inline snippet in references/claude-web-api-extraction.md assembles a transcript in-page in a single call.