Windows 上有个很怪的小毛病，已经有好一阵子了。
我复制一张图片，马上粘贴就正常；稍微慢一点，大概一两秒，图片就没了。文字一直正常。机器上开着微信输入法跨设备同步、网易 UU 远程（本机进程名是 GameViewer），以及 Windows 远程桌面客户端 mstsc。它们都会碰剪贴板，一眼看不出是谁干的。
这个问题我一直想弄清楚。网上也搜到过有人把类似症状指向微信输入法的跨设备同步，可这个功能我还要用。把它关掉只是绕开问题，也没法说明图片究竟是怎么丢的。
真要往下查，得知道 Windows 剪贴板里有哪些格式，得看 owner 和进程，还得写点 Win32 代码捕时间线。找工具、查 API、写代码、测结果，每一步都不太难，凑在一起就很耗时。以前始终没找到能把这些环节串起来的头绪。
这次我没再停在搜索结果上。我把现象、机器上正在运行的同步程序，以及“跨设备同步还要继续用”这个条件一起告诉 Codex，让它直接写观测代码，跟着剪贴板日志往下查。
图片先被读取，再被改写成临时文件，还可能被远程桌面再次清掉。守护程序等到粘贴前才恢复位图。
谁读过，谁改过
Codex 先写了一段观测代码，记录每次剪贴板变化时的格式和 owner。
图片刚复制进去时，剪贴板里有 CF_BITMAP、CF_DIB 和 CF_DIBV5。网易 UU 远程的 GameViewer 进程很快读了一次，格式没变。这先排掉了一个很容易犯的错：进程出现在剪贴板访问记录里，不证明它改了内容。
后面的变化就很实在了。wetype_server 读取图片，往 %USERPROFILE%\AppData\LocalLow\Tencent\WeType\ClipboardTmp 写入一张 PNG，再把剪贴板换成这个临时文件的 CF_HDROP / FileDrop。原来那几种位图格式全消失了。
本机的微信输入法版本是 2.1.2.11。我只在这台机器上捕到过这条路径，所以结论也只到本机为止。目前还没有对照微信输入法的官方说明、更新记录或社区讨论做外部核验。
更麻烦的是 mstsc。它有时会接着接管剪贴板，把图片格式和 WeType 刚放进去的 FileDrop 一起清掉。两个同步组件前后改写，才组成了我真正遇到的故障。只找到第一个改写者，修复会漏掉后半截因果链。
第一个修法太直观了
看到图片被清掉，自然会想到马上写回去。第一版就沿着这个思路：缓存原图，发现位图格式消失，立刻恢复。
跑起来才看出不对。我们的守护程序也成了剪贴板的一个竞争者。刚写回去的图，一秒后又可能被 WeType 或远程桌面改掉。守护程序如果一直抢，剪贴板反而更乱，还有可能碰到正常文字和文件。
这次测试之后，恢复时机改到了粘贴之前。
现在的程序用 WM_CLIPBOARDUPDATE 观察格式，在内存里暂存 CF_DIB、CF_DIBV5 和 PNG。它只认两类干扰信号：一类是 wetype_server 写入的单个 ClipboardTmp PNG；另一类只在严格时间窗口、特定 owner 和格式丢失组合下启用兜底。条件收得很紧，是为了少碰普通复制。
保存好图片后，程序通过 WH_KEYBOARD_LL 等 Ctrl+V。按键真的出现时，它赶在目标应用读剪贴板之前把位图放回去；如果此前捕获到 WeType 的 FileDrop，就一并保留。缓存最多留十分钟。复制文字或普通文件时，它不插手。
这个后台程序用纯 Win32 C# 写成。它没有注入微信输入法，也不会去改它。
测试过了，图还是会没
第一版做完后，集成测试过了。测试脚本往剪贴板放一张图，等 WeType 将它改成临时 PNG，再调用恢复。DIB/DIBV5 回来了，这条单轮路径已经跑通。
自动测试结束后，我开始正常用电脑，连续粘贴了几次，图片又丢了。我就在当时的 Codex 任务里回了一句：
感觉不太行……还是会贴着贴着就没了。
收到这条反馈后，Codex 重新检查守护程序日志。第一次恢复确实成功，随后 mstsc 又清了一次。旧逻辑把同一张图的第二轮干扰当成新内容，连缓存也删了。
状态机又改了一轮。只要某张图已经确认被 WeType 干扰，十分钟内的后续清除都还算这次会话。WeType 或远程桌面可以再清，守护程序就在下一次粘贴前再恢复。用户复制了文字或其他正常内容，它才丢掉旧图。
修订后的测试跑出了完整的两轮：初始有 DIB/DIBV5；约 1157 ms 后，WeType 让位图消失并放入 FileDrop；第一次恢复后，位图、FileDrop 和守护程序标记都在；随后 mstsc 连图片和 FileDrop 一起清掉；第二次恢复也成功。文字对照组只保留 UnicodeText，没受影响。
“还是会没”没有什么技术细节，却直接否定了“恢复一次就够”的测试假设。如果当时只看自动测试，这个程序就会停在一个真实使用中仍然会失败的版本上。
工具链终于能跟着问题走了
这次让我印象比较深的，是 Codex 能在很散的技术面之间继续干活。它写剪贴板观测，读进程 owner 和格式，再用 Win32 做键盘钩子。第一版失败后，它还能继续翻日志、改状态、补测试。
以前的 AI 也能解释 WM_CLIPBOARDUPDATE，或者给一段 C# 示例。可一旦问题跨过几个工具，人通常还得自己把每一段拼起来。现在 Codex 可以把这条链继续往下跑。我没有先花半天熟悉整套剪贴板 API，问题已经进入了可测的实现阶段。
至少在这次排障里，我感到门槛的位置变了。以前更吃一个人对整条工具链的熟悉程度，现在更吃对问题的判断。
可 Codex 自己看不到我怎么用这台电脑。跨设备同步不能直接关掉，这是我给的条件。网易 UU 远程的 GameViewer 进程读过剪贴板，是不是它改的，还得看前后格式。自动测试显示成功，连续粘贴时却又失败，这也只有正常使用时才会知道。
所谓人在回路，这回其实很简单。Codex 把观测代码、守护程序和测试做得很快，我把做出来的东西拿来正常用。出了问题，我就在同一个 Codex 任务里把问题说清楚。要是自动测试通过后我没再继续用，这次排障就停在第一版了。
先当作本机修补
目前这只是本机兼容层，正在继续实用验证。它只能在键盘 Ctrl+V 之前恢复，管不了右键菜单里的粘贴。程序不主动提权，对管理员权限的目标应用仍有边界。双轮回归通过了，仍然需要更长时间和更多图片来源的验证。
这篇我仍把它归到 Agentic Ops。代码是现场排障里的一段工具，主线仍是人和 AI 怎么把一个古怪、细碎、过去特别吃经验的问题往前推。这次之后，我会更愿意把同类疑难杂症交给 Codex 先查，然后自己继续盯住它有没有真的解决。