A One-Off Script to Bulk-Delete Your Claude.ai Conversation History

Anyone who has accumulated hundreds of conversations on claude.ai and tried to clear them out has probably hit the same wall: the "Select all" checkbox on the /recents page only selects the rows that are actually rendered in the DOM. Web apps that use virtualized or paginated lists only mount a handful of items at a time, so "all" really means "all twenty or so things currently on screen." Delete those, scroll, repeat. For an account with a long history, that is a lot of manual cycles.

Developer Matteo Leonesi published a small script that sidesteps the UI entirely. Instead of clicking checkboxes, it talks directly to the internal API that the claude.ai front end already uses, enumerating every conversation in an account and issuing delete calls against the full set rather than the visible subset.

What it actually does

The tool is a single delete-all.js file meant to be pasted into the browser's developer console while you are logged in and sitting on the /recents page. Because it runs inside the authenticated page context, it inherits your session cookies and can hit the same backend endpoints the app calls. There is no separate authentication step, no token to copy, and no third-party server involved. The code runs locally in your tab against Anthropic's own API.

The usage is deliberately low-tech:

1. Open https://claude.ai/recents.
2. Press F12 and switch to the Console tab.
3. Paste the contents of delete-all.js and hit Enter.
4. Confirm the dialog that appears, one prompt per organization on the account.

The per-organization confirmation matters because a single Claude login can be attached to more than one workspace (a personal account plus one or more team or enterprise organizations). The script walks each org it finds and asks before touching it, so you are not silently wiping a shared team workspace when you only meant to clean up your personal chats.

Why the "Select all" limitation exists

This is not a bug so much as a side effect of how modern list rendering works. To keep a page responsive when a list could contain thousands of entries, front-end frameworks render only the elements near the viewport and recycle them as you scroll. A "Select all" control wired to the rendered rows therefore selects only what is mounted. Building a true select-all means tracking selection state separately from the DOM and reconciling it against a server-side count, which is more work and a common thing for product teams to defer.

Calling the API directly avoids the question altogether. The backend knows the complete list, so iterating over it server-side gives you the real "everything" that the UI cannot.

The patience caveat

The README is upfront about two rough edges, and they are worth taking seriously. First, deleted conversations vanish from the interface slowly, over several minutes, rather than all at once. That lag is the UI catching up with a queue of delete operations, not a sign the script stalled. Second, and more important, you have to keep the tab open and stay on the page until the console prints Finished. Closing the tab, refreshing, or navigating away can halt the loop midway, because the script's execution context dies with the page. If that happens you would be left with a partially cleared account and would need to run it again.

That fragility is inherent to console scripts. They are not background jobs; they live and die with the page that hosts them. For a one-time cleanup that trade-off is fine, but it is the reason this is a personal utility rather than something you would schedule or automate.

A few things to weigh before running it

Pasting code into your browser console is a category of action worth a moment of caution in general. The standard advice applies: read the script first, and only run something you actually understand. In this case the file is short enough to skim, and it depends entirely on relying on an undocumented internal API. Internal endpoints are not a stable contract. Anthropic can change request shapes, response formats, or rate limits at any time without notice, and when they do, a script like this can break or behave unexpectedly. There is no guarantee it keeps working past any given front-end update.

Deletion is also irreversible. There is no trash or undo for cleared conversations, so a bulk run is a one-way operation by design. That is the entire point, but it means double-checking which organization you are confirming each prompt for.

For users who just want a tidy account and have been putting off the manual grind, the project fills a real gap that the official UI leaves open. It is a reminder of a broader pattern in consumer software: when a product's interface only exposes part of what its API can do, the missing capability tends to get reconstructed by users who go straight to the network layer. The source is on GitHub for anyone who wants to read it before running it, which, for any console snippet that deletes data, is the right order of operations.