Mac 终端里听写没反应？先查安全键盘输入

在 iTerm2 里给 Claude Code 口述一段需求，按下触发键。用默认的 fn，气泡照样弹出来，只是没贴上文字，换来一张卡片——「有 App 开着安全输入，暂时无法粘贴」。换成别的触发键，那才是真没反应：没气泡，没提示音。切到备忘录都正常，切回终端又原样——不是 bug，是安全键盘输入（Secure Keyboard Entry）在做它该做的事，听写 App 正好站在它的射程里。

症状：只有终端在前台时，触发键才失灵

先和其他几种「听写没反应」分开：

刚装好就到处都没反应？ 通常是 fn 被 macOS 绑去了表情符号或切换输入法，或者辅助功能没授权，见fn 键冲突那篇。能开始录音但什么都不出来？更像语言包没下载，见Mac 听写没反应、不出字。
只在 Terminal、iTerm2 或其他终端里失灵，一切走就恢复？ 这篇就是写给你的。
昨天还好，今天所有 App 里都失灵，你什么都没改？ 多半是某个后台 App 开了安全输入忘了关。同一套机制，下面一起讲。

安全键盘输入到底做了什么

macOS 有一个系统级开关，叫 secure event input。哪个 App 想让你的按键只到它这里、别处一概收不到，就把它打开。设计初衷是密码框。终端把它做成一个菜单项，因为终端就是你敲 passphrase 和 sudo 密码的地方。

代价写在 Apple 的技术说明 TN2150 里：只要有任何一个进程开着这个开关，系统就停止向所有键盘拦截进程投递按键事件，「whether that process is in the foreground or background」（2026-09-18 查阅）。但拦截不是一刀切：纯修饰键的事件照样送得到，只有普通按键会被挡——Wispr Flow 的帮助文档写的是「macOS keeps delivering modifier-key events but blocks regular key presses, so holding Fn works」。

ListenIn 恰恰靠 event tap 读触发键。fn、Right ⌘ 这类单独的修饰键没法注册成普通热键（系统的热键 API 只收「键 + 修饰键」组合），事件监听是唯一能看见它们的路。这条区分决定了你会看到什么：默认的 fn 是纯修饰键，监听照样收得到，录音照样开始，被挡住的只是后面那次粘贴。换成 F5 或自己录的组合键，走的就是普通按键那条通道，终端开着安全输入时会彻底没反应：没有气泡，没有卡片。iTerm2 的菜单文档把话说得比较轻：这个选项「may disable global hotkeys in other programs」。

注意「other programs」这几个字：聚焦窗口之外的键盘监听，按设计都拦在外面——只是拦得不一样彻底。

找出是谁开着它

三个地方，按可能性排。

终端自己的菜单。 Apple《终端使用手册》简体版给的路径是「终端」>「安全键盘输入」，打开时菜单项旁有勾号（简体页）。用繁體介面的读者注意：同一个选项在繁體手册里叫「加密的鍵盤輸入」，在「終端機」菜单下，字面上没有「安全」两个字，翻菜单时别漏过。iTerm2 的同名选项在 iTerm2 菜单下。菜单位置随版本变，找不到就在「帮助」里搜 Secure。别以为一点别处它就自动关了：Wispr Flow 文档提到「Terminal’s Secure Keyboard Entry stays active in the background」，真正管用的是去菜单手动取消勾选，不是切换窗口。

一个密码提示。 只在 sudo 或 ssh 等密码的那几秒失灵，回车后就恢复，可能是终端为这个提示临时开了安全输入，用完就放，没什么要修的。

一个忘了松手的 App。 TN2150 写明，进程用完必须调用 DisableSecureEventInput；不调用就会全系统挡住键盘监听，直到它退出或想起来。停在登录表单的浏览器标签页、密码管理器、来了又走的锁屏，都可能是它——这就是「到处都失灵」的那种。找持有者：

ioreg -l -w 0 | grep SecureInput

有进程开着安全输入时，这条命令会打出一行 kCGSSessionSecureInputPID，后面跟进程号；ps -p <pid> -o comm= 通常能报出它的名字——但若是后台 App 举起的开关，macOS 可能报成当时前台的那个，名字仅供参考。没人开着时 grep 什么都不打印，这本身也是答案（本机 macOS 26 上试过，0 行）。找到了就退出那个 App，或切过去再切回来。

为什么「直接关掉」不该是默认答案

论坛最常见答案是「把安全键盘输入关了」。管用，代价是：从此每个能看键盘的进程，听写 App 也算，都能看到你在那个专门输密码的窗口里敲了什么。Apple 手册把提醒放在打开之前：「请确保其他 App 不要求从『终端』获得按键输入」（《终端使用手册》简体版）。听写 App 不需要你的按键，它需要的是一个放文字的地方。这是两件事。（Apple、iTerm2、Wispr Flow 文档均 2026-09-18 查阅。）

所以该问听写 App 的不是「要关掉它你才能用吗」，而是「它开着的时候你怎么办」。

听写 App 该做的：不粘贴，给一张复制卡

答案是不粘贴。安全输入的目的就是把其他进程的键盘事件挡在终端外，听写 App 合成的 ⌘V 正是这种事件。谁说有干净的办法穿过去，要么在破坏安全控制，要么在夸大。

ListenIn 的做法很笨：每次粘贴之前先问 macOS 安全输入开没开。开着，就不粘；气泡上给你一张卡，写着**「有 App 开着安全输入，暂时无法粘贴 · 点击复制」。点一下，文字进剪贴板，然后你自己按 ⌘V。终端处理自己的按键，这从来不在安全输入的拦截范围。听写和 Ask Anything 都过这道检查。AI 指令送到当前 App 也过同一道检查，卡片换成通用的「未能自动填入 · 点击复制」**；路由到另一个 App 则不经过这道检查——先激活，再粘（见语音编程）。

相邻的几种情况，听写走同一条规则；Ask Anything 大体一样，只是没有密码框专属卡，直接落到通用的「未能自动填入」：

情况	你会看到
光标停在密码框里	「密码框里不粘贴 · 点击复制」
从没授权过辅助功能	「开启『辅助功能』即可自动粘到光标 · 点击复制」
⌘V 发出去了，输入框读回来还是旧内容	「未能自动填入 · 点击复制」

fn 按下去若仍是安静无声、没有任何卡片，那就不是这个机制——回上一节找持有者。

往终端里粘贴：剪贴板快照与恢复，以及它的边界

ListenIn 用粘贴插入文字，不是逐键敲进去。一次粘贴整块落下，由终端自己的粘贴逻辑处理，也意味着每次插入都要经过你的剪贴板。具体过程（短版见安全页）：

给剪贴板做快照：上面的每一项、每一种数据类型，不只是纯文本。
把听写结果以纯文本写入，并打上 transient 标记（org.nspasteboard.TransientType），遵守这个约定的剪贴板管理器会跳过它。
稍等一下（约 0.12 秒）再发 ⌘V。
约 0.9 秒后恢复快照，前提是剪贴板变更计数没动过；这一秒里你自己复制了东西，以你的为准，恢复跳过。

边界在哪：

它是计时器，不是握手。 macOS 不会通知「目标 App 已读完剪贴板」。这个窗口从 0.4 秒放宽到 0.9 秒，因为大段文字贴进远程桌面、虚拟机时常被读得太晚。目标比窗口还慢，恢复先到，落下去的就是旧剪贴板内容。本地终端少见，但可能。
这一秒里，听写内容就是你的剪贴板。 不理会 transient 标记的剪贴板管理器会把它记下来。
复制卡是一次真复制。 你点卡片时，文字本来就该留在剪贴板上，所以它既不打 transient 标记，也不会被恢复覆盖。

终端还有个特有的麻烦，这条也是听写专属：多数终端不向辅助功能暴露标准可编辑元素，ListenIn 没法事前确认光标是否在能粘贴的地方。辅助功能已授权、安全输入关着，它就照粘，然后读回输入框验证。读得回来、而且一两秒后读回的还是旧内容，才弹**「未能自动填入 · 点击复制」**。根本读不到这个输入框（大多数终端就是这样），它不打扰你。无论哪种，文字都在「历史」里。Ask Anything 更严格，通常直接给复制卡。

范围说明：tmux、SSH、VS Code Remote

写这篇时没有单独测这三样，下面是从机制推出来的，不是测试报告。

tmux。 ListenIn 粘进的是终端模拟器，tmux 收到的是终端转发过来的粘贴内容。安全输入是本地终端 App 的属性，与 tmux 无关。
SSH。 远端 shell 碰不到 macOS 的安全输入。远端的密码提示能挡住你的触发键，只有一种可能：本地终端为它开了开关（见上面「一个密码提示」）。
VS Code Remote。 集成终端是本地 Electron 文本区域，粘贴行为和本地 VS Code 一样，远端不参与。Electron 的辅助功能读回常有延迟，这也是复制卡宁可多等一会才弹的原因之一。

这三样在你那里表现不同，那是我们想收到的报告；Mac 通用设置看常见问题。

安全键盘输入留着。终端里的语音输入只有在它开着时才算安全。触发键失灵，去找是谁开着开关；对听写 App 的期待是把文字递给你，而不是和保护机制争。ListenIn 的 Mac 听写就是这么做的，复制卡也是为此存在。