现象
在 Mac 终端 的 tmux会话 使用 Codex CLI 场景里，复制 DataGrip 的 SQL 后按 Ctrl+V，Codex 可能无反应，并出现类似报错：
Failed to paste image: clipboard unavailable:
X11 server connection timed out because it was unreachable
随后 Enter、Ctrl+C 也可能失效，表现为当前会话像"卡住"了一样。
同样内容如果使用 Command+V，则可以正常粘贴。
原因分析
这次问题的重点不在于 Ctrl+V 和 Command+V 的常规区别，而在于：
在 Mac → tmux → Codex TUI 这条链路里，Ctrl+V 可能触发 Codex 的异常剪贴板处理逻辑。
虽然复制的是 DataGrip 里的 SQL，并不是图片，但图形界面应用复制到系统剪贴板时，往往不只有纯文本，还可能带有富文本、HTML 或其他剪贴板格式。
Codex 在 tmux/终端环境下，可能没有把这次输入简单当作"文本粘贴"，而是误走到了附件或图片相关的 clipboard 检测逻辑，于是报出了 Failed to paste image 一类错误。
一旦这条处理链出错，Codex 当前 TUI 会话的输入状态就可能异常，进一步表现为：
Ctrl+V后没有正常输入Enter失效Ctrl+C也没有正常中断- 整个会话看起来像假死
本质结论
这不是 tmux 本身故障，也不是真的在粘贴图片。
更准确地说，这是：Codex 在 Mac 的 tmux 场景下，对 Ctrl+V 触发的剪贴板内容发生了异常处理或误判，最终导致当前会话输入状态异常，表现为假死。
处理方式
最直接的规避办法
在这个场景里，粘贴 SQL 或其他文本时：
- 优先使用
Command+V或右键粘贴 - 不要使用
Ctrl+V
更稳的使用建议
如果复制来源是 DataGrip、浏览器、飞书、Notion 之类 GUI 应用，为了减少异常剪贴板格式带来的影响，可以这样做：
- 先粘贴到纯文本编辑器
- 再重新复制纯文本
- 使用
Command+V粘贴到 Codex
如果是大段 SQL、脚本或日志，更稳的方式是：
- 先保存成文件
- 再让 Codex 读取文件内容
如果已经卡住了
方法 1：直接杀掉当前 tmux pane
Ctrl+b x方法 2：从别的终端定位并杀掉 pane
tmux list-panes -a -F '#S:#I.#P #{pane_current_command} #{pane_pid}'
tmux kill-pane -t 会话名:窗口.面板例如：tmux kill-pane -t test-session:0.0
方法 3：直接杀掉 codex 进程
ps -ef | grep codex
kill -9 <pid>