Zui近把主力终端换成了 Warp，用下来体验不错——AI 补全、命令分组、界面好kan。但有一个习惯一直没改：重度依赖 tmux 管理会话。

Warp 自带分屏和多 Tab，日常用够了。tmux 留给 SSH 远程场景。

某天我在 tmux session 里启动 Claude Code，想把终端里的一段报错信息复制进去让它分析。Cmd+C 复制，切到 Claude Code 输入框，Cmd+V——

输入框纹丝不动。

以为是偶发，重试几次还是不行。换成手动重新输入，Neng用，但几十行的报错显然不可Neng手打。

去翻了一下 Claude Code 的 issue，发现有类似反馈，但没有定论。先排除。

在 tmux 内，Cmd+V 这个动作经过的路径大概是：

系统剪贴板 → Warp 拦截 → tmux pty 层 → 应用输入框

中间任何一层处理不对，内容就丢了或者发不进去。

左边窗口跑着 Claude Code 在重构数据库,右边窗口 Codex 在写单元测试,中间还夹杂着 Gemini CLI 的代码审查提示。我突然意识到:这不是在写代码,这是在指挥一个 AI 交响乐团 。

Claude Code 用 Ink渲染 TUI，输入框的事件处理和普通 shell prompt 不同，对这条链路geng敏感。

tmux 有自己独立的 paste buffer，和系统剪贴板是两套东西。

tmux 有自己的粘贴命令，但这走的是 tmux buffer，不是系统剪贴板，复制过来的内容根本不在这个 buffer 里无效。

# 终端类型
set -g default-terminal "xterm-256color"
set -ag terminal-overrides ",xterm-256color:RGB"
# 让 Warp 的转义序列Neng穿透 tmux
set -g allow-passthrough on
# macOS 剪贴板修复
set -g default-command "reattach-to-user-namespace -l zsh"
# 同步 copy-mode 到系统剪贴板
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "pbcopy"
bind-key -T copy-mode MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "pbcopy"

set -g set-clipboard on 这行配置本来以为Neng解决，结果重启 tmux 后还是不行。

三个因素叠加，才让这个问题这么难察觉——单独用其中任意两个dou不会稳定复现。

brew install reattach-to-user-namespace

然后在 ~/.tmux.conf 加：

set -g default-command "reattach-to-user-namespace -l zsh"

把几个相关配置一起整理进 ~/.tmux.conf:

重启后tmux kill-server ,重新进入 session，再试——粘贴成功了！！ 环境：macOS + Warp Terminal + tmux + Claude Code