I’m seeing a UI clipboard bug in ZeroTraceGPT.

[cyan reef]

Issue:
When I click the Copy button on a model response, the clipboard contains text that was never visible in the UI. The screen shows a short response (e.g., 1–2 sentences), but the copied text includes a much longer hidden paragraph.

Steps to reproduce:

1. Generate a response (especially with reasoning/instruct models like DeepSeek or DarkIdol).
2. The UI displays a shortened or rewritten answer.
3. Click the Copy button.
4. Paste into a text editor.

Expected:
Clipboard matches exactly what is visible on screen.

Actual:
Clipboard includes hidden or previously generated text that was not rendered.

Likely cause:
Copy button appears to be bound to the raw generation buffer or token stream, not the rendered DOM output.

This is the same “copy-from-buffer vs copy-from-DOM” issue seen in other local LLM UIs with streaming or post-processed output.

[tranquil shuttle]

Hi @cyan reef. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

---

The knowledge sources you provided don’t mention ZeroTraceGPT or the specific clipboard behavior you’re seeing, so I can’t confirm implementation details for that app. I can only infer from similar issues in GPT4All and related tooling.

In GPT4All Desktop, there is a known distinction between what’s stored/saved internally and what’s exposed via the “Copy Conversation” button; chats are saved in a format that’s “not in an easy way to export to other programs,” so copying is done via a dedicated UI action rather than by reading the on-disk format directly. [Chat logging] This suggests that, in GPT4All, the copy feature is intentionally tied to the rendered conversation, not the raw backend buffer.

Your description (“copy-from-buffer vs copy-from-DOM”) matches a class of bugs that can occur in UIs that:

• Stream tokens from the model, then
• Post-process or truncate the visible text, but
• Still use the original raw buffer as the source for the Copy action.

However, the GPT4All docs and issues you shared do not explicitly describe this exact bug or a fix for it, nor do they mention ZeroTraceGPT at all. [Troubleshooting]

Given that limitation, the most I can say based on the available sources is:

• GPT4All itself uses a dedicated “Copy Conversation” mechanism to export what the user sees, rather than exposing the internal binary/chat format directly. [Chat logging]
• There is no documented, official guidance in these sources on a mismatch between copied text and visible UI text, nor any mention of ZeroTraceGPT’s implementation.

If ZeroTraceGPT is built on top of GPT4All, the likely fix (from a UI perspective) would be to ensure the Copy button reads from the final rendered message content (DOM / React state / post-processed string) rather than from the raw generation buffer—but that’s an inference, not something stated in the docs.

Because the knowledge sources don’t cover ZeroTraceGPT or this specific bug, I can’t provide a definitive, documentation-backed fix.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

@cyan reef Kapa.ai is still learning and improving, please let me know how I did by reacting below.