SSH 到远程服务器、在 tmux 里跑 Claude Code，怎么用语音输入
远程开发的人大概都碰过这个场面：在本地终端里用语音说得好好的，ssh 进服务器之后，同一个按键按下去没反应了。你以为是权限没给、是哪个配置写错了，排查半天才发现根本不是那回事。
这件事值得单独讲，因为它的原因比大多数人想的更底层，而且一旦理解了原因，该选什么方案是自明的。
官方文档是怎么写的
先把事实摆出来。Anthropic 的 Claude Code 文档在 voice dictation 的「Requirements」一节里列了三条硬性要求，其中一条是：
A local microphone: voice dictation does not work in cloud sessions or SSH sessions.
同一页还有一段讲 VS Code 扩展的，说明写得更直白：
The Claude Code VS Code extension also supports voice dictation with the same claude.ai account requirement. It is not available in VS Code Remote sessions, including SSH, Dev Containers, and Codespaces, because the microphone is on your local machine and the extension runs on the remote host.
注意最后那半句——「because the microphone is on your local machine and the extension runs on the remote host」。这是 Anthropic 自己给出的机械解释，而不是外部的猜测。它也顺便说明了：SSH、Dev Container、Codespaces 这三种形态在这件事上是同一个问题，没有谁比谁更有希望。
这是物理约束，不是产品缺陷
把上面那句话展开，就是整篇文章的骨架：
麦克风是插在你本地机器上的物理设备。 不管是笔记本内置的、USB 的还是蓝牙的，它的音频数据先进入本地操作系统的音频子系统。
SSH 转发的是终端会话，不是音频流。 SSH 搬运的本质上是一串字节：你敲的键过去，远端的输出回来。它不是一条音频通路。
于是任何试图在远程主机上采集音频的方案，根本没有音频可采。 远端那台机器大概率连声卡都没有——它是台云服务器。Claude Code 文档的 troubleshooting 一节里甚至专门写了这种情况的报错，提到「a headless server or a container」没有音频采集设备时会如何。进程跑在哪台机器上，就只能听见哪台机器的麦克风。
这不是「还没做」，也不是「配置不对」，是架构位置决定的。同样的约束对任何把语音能力做进远端进程里的工具都成立——具体哪家 CLI 在哪个版本有什么形态的语音入口，变化很快，以各自官方文档为准，但结构性的那部分不会变。
反过来，哪一类方案不受影响
答案也从同一个道理里来：在本地图形层工作的方案。
它的工作流是这样的——在本地听、在本地识别、把识别结果作为键盘事件送进当前获得焦点的那个窗口。整条链路从头到尾没有离开你的本机。
关键在最后一步：对这类工具来说，它面对的只是「当前聚焦的窗口」这个抽象。那个窗口里跑的是什么，它不知道也不需要知道——
- 本地 shell？文字就落进本地 shell。
- tmux 会话？tmux 收到的是按键，和你真敲键盘没区别，照常处理。
- SSH 到远程机器的会话？按键经由 SSH 送到远端，和你手敲的那些字符走的是同一条路。
- VS Code Remote、Dev Container 里的终端？同理。
它不需要知道那条连接通向哪里，因为它就是在「打字」。 打字这件事从来不受 SSH 影响——否则你连命令都敲不进去。
语音狗子 属于这一类：长按右 Option 说话，松手后文字落在光标处；识别用 FunASR SenseVoice 在本机完成，音频不出设备，断网也能用，没有 API Key、没有账号。它对终端里跑的是什么完全无感知——这正是它在远程场景里还能用的全部原因，不是什么特殊适配。
需要说清的代价是：这类方案要授予辅助功能和输入监听两项系统权限，权限本身能力不小，值得花一分钟确认工具的数据流向。另外语音狗子仅支持 Apple Silicon + macOS 13 及以上。
为什么剪贴板方案在 SSH/tmux 下更容易出事
有一类常见的变通做法是：用某个听写工具转写成文字，复制，再粘贴进终端。在纯本地环境这完全可用（我们在另一篇里把它列为零配置零风险的选项）。但一旦涉及远程和 tmux，它会多出几层容易出问题的环节：
剪贴板不是同一个。 远程主机有它自己的剪贴板（如果有图形环境的话），你本地也有一个，两者默认毫无关系。
tmux 还夹了一层。 tmux 有自己的 paste buffer，复制粘贴先在它的体系里打转。
OSC 52 这条路要全链路配合。 让远端的复制动作落到本地系统剪贴板，通行做法是 OSC 52 转义序列。但这是一条链：远端程序发出序列 → tmux → SSH → 本地终端模拟器 → 系统剪贴板，每一层都必须正确放行。tmux 这边涉及 set-clipboard 的取值（off 会直接剥掉，on 和 external 行为不同），较新版本还可能需要 allow-passthrough；终端模拟器那边是否支持、默认是否开启，各家不一。具体到你自己这套组合能不能通，需要自行验证，别假定。
而模拟键盘输入的方案完全不经过剪贴板。上面这些配置成不成立，对它没有影响。
SSH 场景下特别要注意的一个开关
这条在远程场景里出现的概率比平时高得多，所以单独拎出来。
安全键盘输入（Secure Keyboard Entry）。 Terminal 和 iTerm2 都有这个选项，开启后 macOS 进入 Secure Event Input 状态，停止向第三方程序的事件监听（event tap）派发按键。后果是所有靠监听按键触发的工具——包括全部这类语音输入工具——在那个终端聚焦时完全收不到你的按键，而且没有任何报错。
为什么在 SSH 场景格外要提？因为开着这个开关的人里，相当一部分正是因为要在终端里敲 SSH 密钥口令、sudo 密码、服务器密码才开的——这恰恰是远程开发的日常。你很可能是有意打开它的，然后忘了。
Terminal 在「终端」菜单里取消勾选，iTerm2 在 Preferences → General。更详细的排查过程见这篇。
如果你出于安全考虑必须一直开着它，那么模拟键盘输入这条路在那个终端里就是走不通的，转写后粘贴反而成了唯一稳妥的办法。
顺带：远程场景下的两条实际建议
别念路径和标识符。 这条在哪都成立，远程场景更明显——远端的路径往往更长更陌生。中文语音识别对驼峰命名、下划线、英文缩写的还原能力普遍有限，语音狗子用的 SenseVoice 在架构上不支持热词定制，这块是公开的短板。说「改一下那个处理 webhook 回调的文件」让 AI 自己定位，比逐字念路径可靠得多。
说完检查再回车。 本地跑错一条命令可以撤销，远端服务器上往往不能。把「说」和「执行」分成两个动作，在远程场景下不是习惯问题，是安全问题。
小结
远程开发时内置语音功能不可用，不是哪家产品偷懒。麦克风在本地、进程在远端，这个位置关系决定了结论，Anthropic 自己的文档把话说得很清楚。
绕过它的方法只有一个方向：把语音这一环留在本地。在本地听、在本地识别、把结果当键盘输入送出去——到那一步之后，无论下游是 shell、tmux 还是一条通向地球另一端的 SSH 连接，都只是在接收你「敲」进去的字符而已。