[BUG] Desktop app (macOS): copying text in the in-app Browser pane silently fails — the clipboard is never written

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?

In the Claude Code desktop app on macOS, copying text from a page rendered in the in-app Browser pane does not write anything to the system clipboard.

The copy appears to succeed — there is no error, no warning, and no visual difference from a successful copy. But pasting afterwards yields the previous clipboard contents, so it looks like the paste target simply received nothing.

The silence is what makes this damaging. In my case I copied a freshly created API key (a value the provider displays exactly once) from a page open in the Browser pane, and pasted it into a hosting provider's environment-variable field. The field was saved empty. Because that provider masks secret values after saving, the empty value was invisible in its UI, and the resulting failure surfaced only as "the feature doesn't work" much later. It took several days of debugging to trace it back to the clipboard never having been written.

Performing the identical copy on the identical page in Google Chrome works correctly, so the page itself is not the problem.

What Should Happen?

Copying text in the in-app Browser pane should place that text on the system clipboard, exactly as a normal browser does.

If the app is unable to write to the clipboard (permission, focus, or sandboxing restrictions), it should surface a visible error instead of failing silently. A silent no-op is far more harmful than a visible failure here: the user has no way to know the copy did not happen, and for a one-time secret the original value may no longer be retrievable by the time the problem is noticed.

Error Messages/Logs

None. No error message, toast, or warning is shown anywhere in the app when the copy fails — this silence is the core of the report.

Steps to Reproduce

1. Open the Claude Code desktop app on macOS.
2. Open any web page containing selectable text in the in-app Browser pane (for example, ask Claude to navigate to a page, or open the Browser pane directly).
3. Put something known on the system clipboard first, e.g. copy the text SENTINEL from any other app. This makes the failure unambiguous in step 6.
4. In the Browser pane, copy some text from the page — either by selecting it and pressing ⌘C, or by clicking a "copy" button provided by the page itself. Both routes reproduce the problem.
5. Switch to any other application (or any text field outside the Browser pane) and paste with ⌘V.
6. Observed: SENTINEL is pasted — the clipboard was never overwritten by step 4. No error was shown at any point.
7. Expected: the text copied in step 4 is pasted.
8. Open the identical page in Google Chrome and repeat steps 3–5 → the copied text is pasted correctly, confirming the page is not at fault.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.139 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• Claude Code desktop app for macOS (not a terminal session). The "Terminal/Shell" dropdown above has no option matching the desktop app, so please disregard whatever it defaults to.
• macOS 26.5.2 (build 25F84), Apple Silicon.

Why this is worth prioritising despite being "just" a copy failure

The Browser pane is frequently used for exactly the kind of page where a value is displayed once and cannot be recovered — API key creation screens, one-time tokens, recovery codes. A silent clipboard no-op in that context does not merely inconvenience the user; it destroys a value that no longer exists anywhere else, and it does so without any signal that something went wrong.

In my case the downstream symptom was "the feature I just built doesn't work". The empty value had been saved into a secret field that masks its contents, so nothing in any UI indicated a problem. Diagnosing it required reading server-side runtime logs to prove the environment variable was empty, and only then did the cause trace back to the clipboard.

Suggested fixes, in order of value

1. Surface an error when a clipboard write from the Browser pane fails, rather than silently doing nothing.
2. Fix the underlying clipboard write so ⌘C and page-provided copy buttons behave as they do in a normal browser.

Search performed for duplicates
I searched open issues for clipboard and browser copy. The existing clipboard reports I found are about the terminal/TUI (OSC 52, wl-copy, RDP redirection) or Windows image pasting, none about the desktop app's in-app Browser pane, so this appears to be distinct.