[Bug]: Copying from the terminal never works — clipboard always keeps its old content (Windows desktop, remote environment) #8361

Activity

1. callmemorgan commented on Sep 12, 2026

   

   callmemorgan

   on Sep 12, 2026

   Last edited by callmemorgan

   Contributor

   More actions

   Note

   Triage and evidence collected, and this comment written and posted, by GPT-6 Astra in Codex on my behalf.

   +1 for the OSC 52 / Claude terminal-copy part of this issue on macOS. I reproduced it in the installed desktop app, including a fresh Claude session and after fully quitting and relaunching T3. An old conversation, cancellation/resume, and fish are not required for this reproduction.

   Client: T3 Code Nightly 0.0.41-nightly.20260912.1612, macOS 26.6.2, arm64. My existing remote Claude Code session was 2.1.263; a fresh session running 2.1.270 failed too.

   Reproduction without Claude

   1. Put a known marker on the client clipboard and verify it pastes. I used CONTROL-COPY-WORKS, copied through T3's native Edit menu.

   2. Open a terminal in T3. A new terminal from the New thread screen is sufficient; no agent turn or conversation history is needed.

   3. Run this command, which emits an OSC 52 clipboard write for T3-OSC52-test:

      printf '\033]52;c;VDMtT1NDNTItdGVzdA==\a'

   4. Paste into T3's chat composer without sending the message.

   Expected: T3-OSC52-test. Actual: the previous marker remains. No clipboard error is shown.

   Claude reproduction

   In a new T3 thread's terminal on the same remote Linux host, I replaced fish with a clean bash process:

   exec env SHELL=/bin/bash /bin/bash --noprofile --norc

   I launched claude, asked it to reply with T3-CLAUDE-COPY-PROBE without using tools, then ran /copy. Claude displayed Copied to clipboard (20 characters, 1 lines), but pasting into the T3 composer still inserted CONTROL-COPY-WORKS. The existing long-running Claude session gives the same result.

   Comparisons

   All of these tests used the same macOS desktop client:

   Terminal host	Shell / condition	OSC 52 result
   Remote Linux, kernel 7.0.0-31-generic, x86_64	fish; new terminal in existing thread and from New thread	Clipboard unchanged
   Same remote Linux host	Clean bash, SHELL=/bin/bash, terminal modes reset with RIS (printf '\033c')	Clipboard unchanged
   Separate remote CachyOS host, kernel 7.2.2-1-cachyos, x86_64	fish, then clean bash with terminal reset	Clipboard unchanged
   Remote Mac mini, Darwin 25.6.0, arm64	zsh	Clipboard unchanged
   Local MacBook Neo, Darwin 25.6.0, arm64	zsh; no remote connection	Clipboard unchanged
   After fully quitting and relaunching T3	New terminal on the first remote Linux host	Clipboard unchanged

   The original Claude session's /copy also still failed after the desktop relaunch. Direct printf T3-native-pbcopy-control | pbcopy on the local Mac worked, and pasting into T3 returned that exact value. The post-relaunch failures preserved this second control marker.

   Source triage

   I inspected the Ghostty integration in the installed app's source maps and compared core.ts, runtime.ts, and surface.ts with upstream at fcbe45796aea99e9e2a9ce19dd9409fbd7e720e4; all three matched. GhosttyTerminalCore.write passes output to ghostty_terminal_vt_write. The runtime callback wiring handles PTY replies, while the clipboard write in surface.ts handles user selection. I found no OSC 52 clipboard handler in that integration. This supports missing OSC 52 support rather than a listener expiring with session age.

   This confirms the OSC 52 portion of this issue; it does not establish that every keyboard/selection-copy symptom has the same cause. My earlier PR #9949 combined this with broader selection changes. These results are intended to give a narrower reproduction for triage.

   The attached video is an annotated sequence of captured UI states, with terminal/composer crops combined and pauses added for readability. It demonstrates the fresh Claude failure, the bash check, and the post-relaunch failure. No repository code was changed during this investigation.

   t3-terminal-clipboard-repro.mp4
2. tai-commits commented on Sep 17, 2026

   

   tai-commits

   on Sep 17, 2026

   More actions

   +1 from a different client: T3 Code 1.1.0 on iPad, connected to a remote environment on a Windows 11 Home machine (10.0.26200) with the project living in WSL. Claude Code 2.1.272 running in the T3 terminal.

   Two symptoms:

   1. Copy never lands on the iPad clipboard. Ran /mcp in Claude Code to authenticate a new MCP server; it prints an OAuth login URL in the terminal and there is no way to get it onto the clipboard. Claude's own /copy reports success but paste still gives the previous clipboard content, same as the macOS reproduction above.
   2. I cannot select text in the terminal at all on iPad. Long press and drag do not start a selection, so the fallback of selecting the URL by hand is not available either.

   The OSC 52 gap explains the first symptom. The second might be touch-specific and separate; happy to open a dedicated issue for it if that is more useful.