Cannot copy text from Claude responses in interactive TUI (GNOME Terminal, Ubuntu 24.04)

FWIW /tui default fixed this issue for me.

I have the same thing in /tui fullscreen on Fedora 43 - not only does it not auto-copy (though it says it does) but ctrl-shift-C doesn't copy either. /tui default makes it work again.

I'll note that the workarounds given (middle-click) does not work for me

FWIW /tui default fixed this issue for me.

This doesn't fix the issue for me and significantly changes other claude code behavior (e.g., #826), so it's not really a great workaround.

FWIW /tui default fixed this issue for me.

Works for me. The issue only occurred when switching to tui fullscreen a few weeks back.

Works for me.

/tui fullscreen works for you?

The issue only occurred when switching to tui fullscreen a few weeks back.

This is exactly the issue: cannot copy text from Claude responses in interactive TUI with /tui fullscreen.

ue: cannot copy text from Claude responses in interactive TU

No, /tui default works for me.

When I updated Claude a few weeks back, it asked me to try the new fullscreen mode - which I did. This is when I couldn't copy text via mouse. That's the only connection I can make where I started having this issue.

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.

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.

Thanks for proving it with the config. Also confirmed same issue

Confirming issue on Mate Desktop (Gnome 2) as well. This fullscreen renderer also prevents logging in, because of the token back and forth process for the claude code client login. Biggest problem is with my VMs that the company wants us to use for sandboxing. It's a Red Hat based solution with Parallels (Gnome 3).

> ue: cannot copy text from Claude responses in interactive TU No, /tui default works for me.

This issue is about /tui fullscreen breaking the clipboard, not /tui default breaking the clipboard. If /tui default allows cut & paste, that's not this issue. "When I turn my steering wheel to the left, the brakes fail" does not have a workaround "do not turn left, just turn right three times".

When I updated Claude a few weeks back, it asked me to try the new fullscreen mode - which I did. This is when I couldn't copy text via mouse. That's the only connection I can make where I started having this issue.

Seems like you do/did indeed have the issue that /tui fullscreen breaks cut & paste, like the rest of the people I see commenting.

The good news is that I tried /tui fullscreen again now in v2.1.220 and both select+middle-click and select+C-S-c/v work now, so that's pretty good.

This issue is about /tui fullscreen breaking the clipboard, not /tui default breaking the clipboard. If /tui default allows cut & paste, that's not this issue.

The issue was about not being able to copy text. I and others collaborated to determine it was fullscreen mode that caused the issue. @myifaisal proved it through config.

"When I turn my steering wheel to the left, the brakes fail" does not have a workaround "do not turn left, just turn right three times".

Worth keeping threads like this collaborative rather than adversarial. Makes it easier to actually track down root causes.

Seems like you do/did indeed have the issue that /tui fullscreen breaks cut & paste, like the rest of the people I see commenting. The good news is that I tried /tui fullscreen again now in v2.1.220 and both select+middle-click and select+C-S-c/v work now, so that's pretty good.

Thank you for confirming.

> This issue is about /tui fullscreen breaking the clipboard, not /tui default breaking the clipboard. If /tui default allows cut & paste, that's not this issue. The issue was about not being able to copy text. I and others collaborated to determine it was fullscreen mode that caused the issue. @myifaisal proved it through config.

I think we agree the issue was about not being about to copy text to the clipboard; if you were copying text somewhere else than the clipboard, maybe there is a different issue.

> "When I turn my steering wheel to the left, the brakes fail" does not have a workaround "do not turn left, just turn right three times". Worth keeping threads like this collaborative rather than adversarial. Makes it easier to actually track down root causes.

I replied to a different user about the how /tui default was not a useful workaround and you replied to me with the same (IMO) confusion; I now infer (after two replies to you before this "adversarial" comment) that you have a different opinion as to whether /tui default is a useful workaround. It's ok if the workaround for you is not a workaround for me; hopefully the brakes analogy expresses the level of insufficiency for me, but I wasn't trying to imply anything other than a disagreement about the "it's a workaround" opinion.

> Seems like you do/did indeed have the issue that /tui fullscreen breaks cut & paste, like the rest of the people I see commenting. > The good news is that I tried /tui fullscreen again now in v2.1.220 and both select+middle-click and select+C-S-c/v work now, so that's pretty good. Thank you for confirming.

Can you confirm this as well?