[BUG] Copying text (Ctrl+C) from Claude Code window in VS Code fails

Confirming this is still happening on macOS with Claude Code extension 2.1.128 (also reproduced on 2.1.126 and 2.1.123). VS Code 1.118.1 on macOS 15.4 (Darwin 25.4.0), Apple Silicon.

Behavior matches the original report:

• Cmd+C from the Claude Code panel and the prompt textbox does nothing
• Right-click → Copy also fails
• Cmd+V paste works fine
• Restarting VS Code resolves it temporarily

So this isn't Windows-specific and it's persisted across at least the last several extension releases. Happy to provide more detail if useful.

Same here, VSCode Version: 1.119.0, Claude extension 2.1.138, macOS Tahoe 26.4.1 (Darwin 25.4.0), Apple Silicon

Different methods:
Hover the message ❌ does not show anything
Right-click and copy ❌ does not copy anything
Cmd + C ❌ NOPE
Switch to terminal ❌ no f... way
Updating VSCode ❌ (at latest version)

I'm getting really mad at this issue

Same here.
I cannot copy-paste what Claude said to me because of this issue, but basically text selection is disabled in the extension's web view in favour of links (e.g clicks on file references). I don't know if this is true, since I can select the text.

I am also getting completely mad at this issue.

@bcherny think you can have claude check this out, prettyplease 🙏

Similar issue on my end, only that I cannot select an arbitrary block of text if I run CC from a VSC terminal in pop-up window mode, I can only select by double clicking a single word or triple-clicking a single line. Once some text is selected by double/triple clicking, Command-C works fine.
Selecting from a VSCode terminal window (not in a tab in the main VSCode window) works fine.
Selecting from a CC console in a tab in the main VSCode window works fine.

confirm same issue - copy form claude code output chat to anything results in artifacts of the UI not the content selected. No copy button of response and no /copy works anymore. What is going on?

NOTE: The only way I was able to restore select - copy - paste normally is a full ctl=shft=p Developer: Reload Window and then I am able to use copy paste again for a while.

Same issue on windows
Just installed today

same issue Copy, Paste and Select All do not work from either keyboard shortcuts or mouse context menu
Claude extension v 2.1.160
Mac OS Tahoe 26.4.1

Still reproduces on Claude Code 2.1.177

Selecting plain prose text from an assistant answer in the VSCode extension
side panel and pressing Ctrl+C does not copy it to the clipboard. Click-drag
selection either highlights nothing or the copy is silently dropped.
What works: the copy button on rendered code/command blocks.
What's broken: selecting and copying normal message/prose text.

Workaround: Reloading the window restores prose copy — Ctrl+Shift+P →
"Developer: Reload Window". After a reload, selecting and copying text works
again, so the broken state appears to set in during a session rather than
being permanent.

Environment:

• Claude Code extension: 2.1.177
• Editor: VSCode 1.111.0 (native extension, side panel)
• OS: Linux (kernel 6.8.0)

Tried: updating to latest, reloading the window, Alt-drag to force raw
selection. Reload Window is the only thing that restores copy.

Still producing the same error in Claude Extension version 2.1.183, running VS Code Version: 1.125.1

The issue still persists.

Environment:

• VS Code: 1.126.0
• Claude Code Extension: 2.1.195

My workaround:

Add this to your keybindings.json:

{
    "key": "cmd+c",
    "command": "editor.action.clipboardCopyAction",
    "when": "editorTextFocus || terminalFocus || view == workbench.panel.output"
}

Then select the text, right-click once, then cmd/ctrl+c — same as usual, just one extra right-click, no need to reload the window.

<img width="787" height="311" alt="Image" src="https://github.com/user-attachments/assets/bf6e2ca0-d3b0-4d41-a579-294071cd91f3" />

The issue still persists. Environment: VS Code: 1.126.0 Claude Code Extension: 2.1.195 My workaround: Add this to your keybindings.json: { "key": "cmd+c", "command": "editor.action.clipboardCopyAction", "when": "editorTextFocus || terminalFocus || view == workbench.panel.output" } Then select the text, right-click once, then cmd/ctrl+c — same as usual, just one extra right-click, no need to reload the window. <img alt="Image" width="787" height="311" src="https://private-user-images.githubusercontent.com/10084666/614010948-bf6e2ca0-d3b0-4d41-a579-294071cd91f3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI4ODYxNTksIm5iZiI6MTc4Mjg4NTg1OSwicGF0aCI6Ii8xMDA4NDY2Ni82MTQwMTA5NDgtYmY2ZTJjYTAtZDNiMC00ZDQxLWE1NzktMjk0MDcxY2Q5MWYzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MDElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzAxVDA2MDQxOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTI5YzU5ZDFhZjQ5YjE4NGI5MjU0ZGY2ZTc3Zjg2M2RjZmU4ZGYxODU4NjUyZDRhMDE2NTNiOTg5ZGVmMTMwNjImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.EexRnXSoFiG1cCRSLAyu1TSlXqpxsQDKy84dtsApGMU">

Issue still present but your keybinding works:)

Confirming on Linux (X11) as well — so this reproduces on all three platforms now.

Environment:

• Ubuntu (kernel 6.8, X11 session — not Wayland)
• VS Code 1.126.0 (native .deb install, not snap/flatpak)
• Claude Code extension 2.1.204

Symptom matches the other reports: selecting text in the chat panel and using right-click → Copy or Ctrl+C silently fails — the clipboard keeps its previous content. Paste works fine. The copy button on code blocks works.

Possible root cause — I dug into it via DevTools (Developer: Toggle Developer Tools), and the modern async Clipboard API is being denied in the renderer, while the legacy path works:

// with the document focused (deferred via setTimeout + clicking back into the window):
navigator.clipboard.writeText("test")
// → NotAllowedError: Failed to execute 'writeText' on 'Clipboard': Write permission denied.

// legacy fallback:
const ta = document.createElement('textarea');
ta.value = 'test'; document.body.appendChild(ta); ta.select();
document.execCommand('copy'); // → true, and the text actually reaches the system clipboard
ta.remove();

So the system clipboard itself is healthy — clipboard-write permission is being denied for navigator.clipboard in this context, and the copy fails silently because there's no fallback. Falling back to document.execCommand('copy') (or routing copy through the extension host) when writeText rejects would likely fix this on all platforms.

I've been seeing this lack of behaviour on latest releases for the last few weeks. It's infuriating - I type something, can't re-use it elsewhere; I ask for markdown to copy/paste out, I'm unable to do anything but screenshot for OCR. (or burn more tokens regenerating the content - not exactly - in a subsequent turn)

I was able to isolate the mouse selection / copy issue to the fullscreen TUI setting.

The issue occurs when this exists in ~/.claude/settings.json:

{
  "tui": "fullscreen"
}

Environment tested:

SHELL=/bin/bash
TERM=xterm-256color
Connection=SSH
OS=Ubuntu and AlmaLinux

Symptoms:

• Mouse text selection does not work reliably inside Claude Code.
• Copying selected terminal text fails or becomes inconsistent.
• The same SSH client and terminal work normally outside Claude Code.

I tested this on both Ubuntu and AlmaLinux servers. After removing only "tui": "fullscreen" from ~/.claude/settings.json and restarting Claude Code, mouse selection/copy worked normally on both systems.

Workaround:

python3 - <<'PY'
import json, pathlib

p = pathlib.Path.home() / ".claude" / "settings.json"

data = {}
if p.exists():
    try:
        data = json.loads(p.read_text())
    except Exception:
        data = {}

data.pop("tui", None)

p.parent.mkdir(parents=True, exist_ok=True)
p.write_text(json.dumps(data, indent=2) + "\n")
print(p.read_text())
PY

I also confirmed the behavior by restoring the old config with "tui": "fullscreen"; the issue returned immediately. Removing it fixed the issue again.

This appears to be related to fullscreen TUI mode capturing or altering terminal mouse/input behavior in SSH sessions.