[BUG] Virtualized rendering introduced a regression in OS clipboard copy and all browser-native export mechanisms in the claude.ai web interface — working fix demonstrated

Status Open
Maintainer reply None cached
Activity 4 comments · opened Aug 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

---

Summary

A regression in the claude.ai web interface introduced the loss of ability to select and copy conversation transcripts to the OS clipboard, and simultaneously introduced the same regression in every other browser-native mechanism for retrieving page content — Save Page As, Print to PDF, browser print, and DOM-reading extensions. All of these rely on content being present in the page. Virtualized rendering means it is not.

The regression affects all users of the claude.ai web interface who rely on copying or exporting conversation content by any native browser mechanism.

A working fix has been built, tested, and published by an affected user at:

https://github.com/filteredwaterdev/true-ai-export

The fix calls the same internal API endpoint that claude.ai already uses on every page load. The engineering complexity of a native export implementation is demonstrably trivial.

The working fix referenced in this report addresses transcript portability only — it provides a workaround for the export direction. It does not and cannot fix the broken clipboard copy behaviour. That requires a native fix to how virtualized rendering interacts with browser text selection. Both issues are real, both are documented here, and neither substitutes for the other.

---

Environment

  • Platform: claude.ai web interface (browser-based)
  • Browsers confirmed affected: Brave, Firefox, Safari
  • Date regression introduced: approximately June 2026

---

Current Behaviour

Clipboard copy — detailed:

What transfers to the OS clipboard is now determined not by what the user selected but by what happens to be mounted in the browser DOM at that moment. The position and length of what actually transfers bears no guaranteed relationship to the user's selection. For long conversations, the overwhelming majority of the transcript is absent from the clipboard. There is no reported error. There is no warning. No indication of any kind is given that the operation failed. The copy appears to succeed. The data loss is invisible and may not be discovered until much later.

A curious illustration of this regression: Cmd-F browser search works correctly across the full conversation — the browser can find text anywhere in the session regardless of scroll position — while Cmd-C copies only the DOM fragment. The content is accessible to the browser's own find function but not to the clipboard.

Save Page As, Print to PDF, DOM-reading extensions:

All of these are subject to the same regression and produce unusable output. The exact nature of the broken output is unpredictable and varies — it is not described in detail here because it cannot be reliably characterised — but in all cases the output does not constitute a usable record of the conversation when dealing with text samples of sufficient size. These mechanisms are not a viable alternative. They are subject to the same underlying regression and all appear to succeed while delivering unusable output.

All failures across all mechanisms are silent. None produce reported errors.

---

Root Cause

The claude.ai web interface was migrated to virtualized rendering. Under this architecture, only the messages near the user's current scroll position are instantiated in the browser DOM at any given time. Older messages are unloaded as the user scrolls.

Every browser-native mechanism for retrieving page content operates on what is in the DOM. The virtualized rendering migration introduced a regression in not one export pathway but the entire category of DOM-based content retrieval simultaneously.

This is not a server-side constraint

Virtualized rendering does not reduce Anthropic's server load. It has no effect on backend infrastructure. The full conversation is fetched from Anthropic's servers regardless — the complete data arrives in a single API response every time a conversation is opened.

This has been confirmed empirically. The following API endpoint returns the complete conversation transcript in full, in under one second, regardless of conversation length, using the user's existing authenticated session:

/api/organizations/{orgId}/chat_conversations/{conversationId}
  ?tree=true&rendering_mode=messages&render_all_tools=true

This is the same endpoint claude.ai itself calls on every page load. The data is there. It has always been there. Virtualized rendering is a client-side optimisation that affects only what is mounted in the local browser DOM — it has no relationship to what is available on the backend.

---

What Should Happen?

---

Previous Behaviour

For many months the following workflows functioned completely and reliably for conversations of any length:

Clipboard copy:

  1. Select any arbitrary portion of a conversation — a sentence, a paragraph, a single response, or the entire session via Cmd-A / Ctrl-A
  2. Copy to OS clipboard via Cmd-C / Ctrl-C
  3. Paste into any external application

The length of the selection, its position in the conversation, and its distance from the current scroll position were entirely irrelevant. Whatever was selected transferred accurately and completely to the clipboard. This was a primary workflow for a significant population of paying users.

Browser-native export:

  • File → Save Page As → produced a complete, readable HTML file of the full conversation
  • File → Print → Print to PDF produced a complete PDF of the full conversation
  • DOM-reading browser extensions could read and export the complete conversation

All of these worked reliably regardless of conversation length, scroll position, or session duration.

---

Error Messages/Logs

Steps to Reproduce

---

Steps to Reproduce

Clipboard:

  1. Open any conversation of substantial length on claude.ai
  2. Press Cmd-A / Ctrl-A
  3. Press Cmd-C / Ctrl-C
  4. Paste into any plain text editor

Expected: Complete conversation transcript.
Actual: Fragment — only messages near current scroll position
— with no reported error or indication the output is incomplete.

Save Page As:

  1. Open any conversation of substantial length on claude.ai
  2. File → Save Page As → Save as HTML
  3. Open the saved file

Expected: Complete, usable conversation record.
Actual: Broken, unusable output.

Print to PDF:

  1. Open any conversation of substantial length on claude.ai
  2. File → Print → Save as PDF
  3. Open the PDF

Expected: Complete, usable conversation record.
Actual: Broken, unusable output.

---

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is a claude.ai web interface regression, not a Claude Code CLI issue. Filed here in the absence of a dedicated public web UI issue tracker.

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

---

Impact

This regression completely destroys a legitimate, high-value workflow that functioned reliably and that users paid for.

The users most severely affected are those doing text-based knowledge work — research, writing, analysis, legal work, strategy — in long sessions where the conversation transcript is the work product. For these users, the web interface IS the product. There is no API alternative. There is no fallback.

The fact that the virtualized rendering migration introduced a regression in every DOM-based export mechanism simultaneously — clipboard, Save Page As, Print to PDF, extensions — means there is no native browser workaround. Every path a user might try to retrieve their content is subject to the same regression.

This regression is underrepresented in community feedback for a structural reason: the most technically vocal Claude users — developers and engineers — access the platform via API or local tooling and are entirely unaffected. The affected users are less represented in the communities Anthropic monitors. The regression appears smaller than it is from inside Anthropic's feedback systems. It is not small.

A note on a related but separate issue: many users have independently noted that moderate to large text pastes into the Claude input box are silently converted to empty file attachments. That is a distinct regression affecting the paste-in direction. It is not the focus of this issue or of the specific linked project, but it is noted here because it affects the exact same user population and compounds the impact. Claude web UI is broken.

---

Working Fix

The working fix referenced in this report addresses transcript portability only — it provides a workaround for the export direction. It does not and cannot fix the broken clipboard copy behaviour. That requires a native fix to how virtualized rendering interacts with browser text selection. Both issues are real, both are documented here, and neither substitutes for the other.

A user built a working fix and published it at:

https://github.com/filteredwaterdev/true-ai-export

The project provides browser console scripts that call the API endpoint documented above directly, retrieve the complete conversation transcript regardless of length, and deliver it locally in multiple formats:

  • Markdown (full and clean)
  • Plain text (full and clean)
  • HTML (full and clean)
  • JSON
  • PDF — serif (full and clean)
  • PDF — sans-serif (full and clean)

Eleven scripts in total, tested and confirmed working on:

  • Brave (macOS)
  • Firefox (macOS)
  • Safari (macOS) — with one additional user step due to Safari's clipboard security policy

The fix demonstrates two things:

  1. The complete conversation data is fully accessible via Anthropic's own backend API using the user's existing session — no new infrastructure is required
  2. The implementation of a native export function is trivially simple — the hard part is already built and already running on every page load

---

Requested Resolution

Primary request

Implement a native Save to file button in the claude.ai interface that calls the above API endpoint and opens a format picker menu, downloading the result immediately as a local file in the format of the user's choosing.

The true-ai-export repository includes:

  • Eleven working export scripts across four formats plus PDF variants, in full and clean versions
  • Complete UI specification for the button and format picker menu at assets/ui/menu-spec.md
  • Icon assets in SVG, PNG, and React component formats at assets/
  • A proposed button label ("Save to file") and function category name ("Transcript Portability")

Everything needed to implement this natively is in that repository. The proposed API call is already running.

Secondary request

Separately restore the ability to select and copy arbitrary text to the OS clipboard. Restore Save Page As and Print to PDF to produce complete and usable output. These require addressing how virtualized rendering interacts with browser-native content retrieval. They cannot be substituted for by an export script. Both the native export function and the restoration of native browser mechanisms are required.

At minimum

Acknowledge this publicly as a regression, provide a timeline for resolution, and add it to the public roadmap.

---

Additional Context

This issue is filed in anthropics/claude-code in the absence of a dedicated public repository for the claude.ai web interface. It is a web interface regression, not a Claude Code issue. A dedicated public feedback repository for the web interface would be a valuable addition.

---

View original on GitHub ↗

4 Comments

filteredwaterdev · 26 days ago

---

Additional evidence that Anthropic is aware virtualised rendering breaks native clipboard guarantees: the Claude Code fullscreen TUI renderer has the same issue and it is explicitly documented. From the official fullscreen rendering docs at https://code.claude.com/docs/en/fullscreen:

"Only visible messages are kept in the render tree" — confirming virtualised rendering in the TUI.

An entire section titled "Keep native text selection" documents how the fullscreen renderer breaks native clipboard operations, and describes a complex custom clipboard implementation built to work around it. The docs also confirm that the classic renderer, which does not virtualise, keeps the conversation in the terminal's native scrollback buffer where the terminal handles text natively and clipboard operations work as expected.

The same root cause applies to the claude.ai web UI, where no equivalent acknowledgement or workaround exists for paying customers using the interface for text-based work.

Classic rendering is the solution because it restores the condition under which native text handling actually works: the text exists in the layer the OS or terminal reads from — the DOM in the case of the web UI, the native scrollback buffer in the case of the TUI — and selection and clipboard are handled natively without requiring a custom implementation. This is how every normal webpage and every normal terminal session works. The moment virtualised rendering removes content from that native layer, that guarantee is broken and no workaround fully restores it.

The TUI at least offers a user-configurable opt-out — users can revert to the classic renderer and recover native clipboard behaviour. No such choice exists for the claude.ai web UI, and there is no public statement from Anthropic that one is planned. This should be configurable. Memory optimisation via virtualised rendering is a reasonable default for constrained environments, but it should not be imposed on all users regardless of their hardware. A user with 48GB of RAM has no interest in memory optimisation at the cost of losing basic native text selection and clipboard functionality in an interface they are paying to use.

---

filteredwaterdev · 26 days ago

A note on impact: I upgraded my paid plan to complete development of the export scripts linked in this report — work I undertook specifically because the interface was broken and Anthropic had not acted. That workaround only addresses transcript export. The core regression — arbitrary text selection, clipboard copy, paste-in — is a separate and unresolved problem.

These are native OS functions that require no implementation when text is genuinely present in the rendering layer; the virtualisation removed that condition, and with it, the guarantee. No script, extension, or workaround can restore them. Only fixing the rendering layer can.

filteredwaterdev · 25 days ago

Another example of a report with related symptom has just been filed for the fullscreen TUI. #83961 documents silent clipboard data corruption caused by virtualised rendering's internal selection handling during auto-scroll. 11 runs of exactly 26 rendered characters each were silently dropped from clipboard copy with no indication of failure. Switching to /tui default — the classic renderer — fixed it completely. This is a controlled proof that virtualised rendering is the direct cause of silent clipboard data loss across Anthropic's surfaces, and that reverting to classic rendering restores it.

That opt-out is not available to claude.ai web UI users, for whom there is no equivalent rendering toggle and no user-addressable workaround.

filteredwaterdev · 25 days ago

A direct product contradiction worth documenting: Anthropic currently markets context windows of up to 1M tokens on paid plans for certain models on the claude.ai web UI. The virtualized rendering regression means the larger the conversation, the greater the proportion of content that exists outside the rendered layer at any given time, and the more of that content becomes inaccessible to native text retrieval. The feature being sold and the feature being broken scale together directly. A paying user with a large context conversation cannot reliably copy, select, save, or export any meaningful portion of it natively.