[Bug] macOS 2.0.0 粘贴图片偶发静默失败（0.43.x 回归）|| Ctrl+V paste image intermittently does nothing (regression from 0.43.x)

使用的 Kimi Code CLI 版本 / What version are you running?

kimi 2.0.0（darwin-arm64 单文件版，2026-09-17 通过 kimi upgrade 升级）

电脑平台 / Platform

macOS 26（Darwin 25.x），Apple Silicon

问题描述 / What issue are you seeing?

剪贴板里有图片时按 Ctrl+V，偶发性完全没反应：不出现 [image #N] 占位符，也没有任何报错。0.43.x（Python 版）一直正常，升级到 2.0.0 后立刻出现。系统终端（Terminal.app）和 JetBrains IDE 内置终端都能复现，JetBrains 终端里失败率明显更高。

复现步骤 / Steps to reproduce

1. 复制一张图片到剪贴板（是否复现与"从哪个 App 复制"有关，见下文分析）。
2. 运行 kimi（2.0.0），在输入框按 Ctrl+V。
3. 有时出现占位符，更多时候毫无反应。

已做的排查（排除终端问题）

• 用 raw 模式字节读取程序验证过：JetBrains 终端里按 Ctrl+V，进程能收到 0x16 字节——按键确实送达了，终端没有吞键。
• JetBrains 终端不支持 Kitty 键盘协议（CSI ? u 查询无响应），与协议差异无关。
• 在系统终端里模拟 JetBrains 环境变量（env -u TERM_PROGRAM -u COLORTERM TERMINAL_EMULATOR=JetBrains-JediTerm kimi），粘贴图片正常。
• 单独调用内置的原生剪贴板模块（@mariozechner/clipboard-darwin-arm64），在 IDE 进程树下读图正常（hasImage() 返回 true）。

所以问题在 CLI 自身的粘贴处理逻辑里。

根因分析（读自 2.0.0 二进制内置的 JS 代码）

darwin 平台上 readClipboardMedia() 的流程是：

1. 先调 osascript -l JavaScript（JXA 读 NSPasteboard 的文件 URL）尝试解析文件路径，超时只有 1 秒（DEFAULT_LIST_TIMEOUT_MS）；
2. 再走 readClipboardFileMediaViaNativeText(clip)：如果剪贴板带有文件类风味（public.file-url、NSFilenamesPboardType、public.url 等），就置 lookedFileLike = true；
3. 如果 lookedFileLike 为 true 但没解析出媒体文件，直接 return null——剪贴板里仍然存在的原始图片数据（public.png/public.tiff）根本不会被尝试（readClipboardImageViaNative 被跳过）；
4. 回到 handleClipboardImagePaste()，media === null → return false → 走"按文本粘贴"兜底，对纯图片剪贴板来说就是静默无操作：无占位符、无报错。

这能解释所有现象：

• 为什么时灵时不灵：剪贴板是否带文件类风味取决于"从哪个 App 复制的"。纯截图（Cmd+Ctrl+Shift+4）只有图片数据 → 必成功；从访达/微信/浏览器复制的图片常带文件引用 → 容易失败。
• 为什么 JetBrains 终端里失败率更高：osascript 冷启动 + 系统高负载更容易超 1 秒超时；且 macOS "从其他 App 粘贴"授权按责任进程分开计算（Terminal.app 与 IntelliJ IDEA 是两份授权），弹窗没被注意到时会把 osascript 卡到超时。

0.43.x 是直接读图片字节的，所以当时没有这个问题。

期望的修复 / Expected behavior

• 文件路径解析失败/超时时，如果剪贴板里还有图片数据，应回退到 readClipboardImageViaNative()，而不是直接返回 null；
• 粘贴最终没有找到内容时，给一个瞬时提示/报错，不要静默失败；
• 建议把 osascript 的 1 秒超时调大，或缓存结果。

English summary

On macOS, Ctrl+V image paste intermittently no-ops in 2.0.0 (regression from 0.43.x). The keystroke reaches the process (verified at PTY level). Root cause in readClipboardMedia(): on darwin it first resolves clipboard file paths via osascript (JXA, 1 s timeout); when the clipboard has file-like flavors but path resolution yields no media, lookedFileLike === true causes an early return null — the raw image bytes still on the clipboard are never tried, and the paste fails silently. Suggest falling back to native image read, surfacing an error, and raising the osascript timeout.

补充

以上调用链读自 2.0.0 darwin-arm64 SEA 二进制内置的 JS bundle（src/utils/clipboard/clipboard-image.ts、src/tui/controllers/editor-keyboard.ts 区段）。如需更多诊断信息可以随时提供。

Start in src/utils/clipboard/clipboard-image.ts at readClipboardMedia() and then inspect the paste path in src/tui/controllers/editor-keyboard.ts. Reproduce with kimi 2.0.0 using image clipboards from different apps; done means failed file-path resolution falls back to native image data and image paste no longer silently does nothing.