OpenClaw Bug：Control UI 粘贴图片时可能把超大 Base64 文本直接灌进输入框

社区刚出现一条新的 OpenClaw issue：在 Control UI 的输入框里粘贴图片时，系统有可能不会把图片当成附件处理，而是直接把一大段 data:image/...;base64,... 内联文本 塞进 composer。

这不只是“看起来难看”的前端小毛病，它会直接带来运维层面的麻烦：

输入框内容会瞬间失控，难以恢复
失败发送后的草稿恢复逻辑更难判断
如果你手上只有 安装版 dist bundle，想临时热修会非常脆弱

更麻烦的是，issue 里还提到一个关键发现：发送失败后的草稿恢复逻辑，可能本来就已经存在于更深层的 send pipeline。也就是说，如果你在 UI 按钮层瞎补一刀，很可能不是修好，而是把恢复链路补坏。

上游来源： openclaw/openclaw#62604

TL;DR

如果你在 Control UI 里粘贴图片后，输入框直接出现一大段 base64 文本：

先把它视为 Control UI 的粘贴处理 bug，不要先怪用户操作。
不要急着在编译后的 UI bundle 里用“包一层按钮点击”这种方式硬修。
先确认你的安装形态是不是 全局 npm / dist-first 包。
在上游明确修复前，优先采用低风险绕过方案。
如果你是多人协作环境，最好把这个症状写进内部事故说明，避免同事误判成模型或 provider 问题。

这个 bug 实际长什么样

根据 issue 的描述，问题路径很直接：

打开 OpenClaw Control UI 的聊天输入框
复制一张图片到剪贴板
在 composer 中执行粘贴
正常预期应当是生成图片附件；但异常情况下，输入框会直接塞进一长串 data:image/...;base64,... 文本

报告还提到：这个问题在测试 体量更小的本地视觉模型 时会更明显；而在某些 Anthropic API 流程下，症状没有那么容易被看出来。

这点很关键，因为很多团队往往是在“换模型”或“切到更底层的本地工作流”之后，才第一次暴露这类前端输入链路问题。

为什么这比普通 UI 小 bug 更麻烦

普通 UI bug 顶多让人烦，这个问题会直接拉高排障成本。

如果超大 base64 文本直接落进输入框：

用户可能误发垃圾内容，而不是图片
草稿内容会变得臃肿、难读、难恢复
失败发送后的消息状态更难安全回滚
团队在应急时很容易补错层

而 issue 里的第二个发现更值得注意：发送失败时，草稿和附件的恢复逻辑可能已经在更深层 send pipeline 里存在。

这意味着，如果你只是看到按钮层调用了 onSend()，然后在 UI 层随手包一层补丁，极有可能把已有的恢复契约打乱。

为什么安装版更难安全修

报告者是在本地全局安装的 OpenClaw 包里调查这个问题时，发现手头并不是一个常规、可编辑的 Control UI 源码树，而是 编译后的 hashed 静态资源。

这会让本地应急热修变得非常脆弱：

你可能只能去改 dist/control-ui/assets/index-*.js
这个文件是压缩后的
文件名带哈希
变更难 review，也难复现

要注意：这不等于它和之前那类“npm 包缺少 Control UI 资源”的打包事故是同一个问题。

之前的老问题，核心是 发布包缺文件；这次的新问题，核心是 图片粘贴链路把超大 base64 当普通文本塞进 composer。只是两者都共享一个现实困境：如果你手上只有 dist 产物，本地热修都很危险。

如何确认你撞到的是这个问题

建议按下面顺序确认，避免把它和模型故障、附件上传故障混在一起。

1）先用“剪贴板图片粘贴”复现

最简单的确认方式就是按原路径走一遍：

打开 Control UI
复制一张图片
在输入框粘贴

如果输入框里出现一大段 data:image/...;base64,...，而不是生成附件，说明你的症状和 issue 高度一致。

2）确认它是不是只坏在 paste path

这个 issue 讨论的是 剪贴板图片粘贴，不一定代表所有附件上传方式都坏了。

所以排障时最好对照一下：

剪贴板粘贴图片
常规文件附件上传（如果你的安装方式支持）

如果文件附件正常、只有粘贴路径坏了，那么更像是前端 paste handling 的定向问题，而不是整个附件链路坏掉。

3）确认你现在调试的是哪种安装形态

如果你的 OpenClaw 来自全局 npm 包或其他 dist-first 安装产物，那么“现场修补”的风险会显著升高，因为你可能拿不到正常源码树。

这会直接影响你的止血策略：

是先停在 workaround
还是切版本
还是转向源码级修复
还是先等上游澄清，而不是立刻去改压缩 bundle

现阶段更稳妥的绕过方案

方案 A：在受影响环境里先停用“直接粘贴图片”

如果你已经能稳定复现，最稳的短期止血方案其实很朴素：

不要再把图片直接粘贴进 composer
如果有别的附件方式，优先走替代路径
关键业务或无人值守流程里，先不要依赖这条输入方式

这不优雅，但能避免把一个前端 bug 放大成草稿污染或后续 prompt 混乱。

方案 B：没有源码级把握时，不要在按钮层乱补发送恢复逻辑

issue 明确提到：发送失败后的恢复逻辑，可能已经存在于更深层的 send pipeline。

这意味着如果你在 UI 按钮层快速补一个 wrapper，可能会制造二次故障，比如：

恢复逻辑重复执行
草稿状态前后不一致
文本恢复了但附件没恢复，或反过来

尤其当你是在编译产物上改补丁时，更不该“先改了再说”。

方案 C：把 dist bundle 热修视为最后手段，而不是默认动作

如果你手上能改的只有安装目录里的哈希压缩 bundle，那就应该把它视为最后手段。

原因很现实：

补丁难 review
后续升级会直接覆盖
复原和迁移成本高
很容易只修表面症状，却破坏 send pipeline 的契约

上游大概率需要修什么

从当前 issue 看，上游大概率至少要检查四层：

Control UI 的剪贴板图片解析逻辑
data:image/...;base64 是否被错误地当作普通文本输入
发送失败后的草稿恢复逻辑究竟应该归属哪一层
安装版分发是否需要更好的 source-to-dist 调试可追踪性

另外，这个 issue 也给出了比较明确的回归测试方向：

composer 的图片粘贴处理
发送失败后，草稿文本与附件是否都能正确恢复

什么情况才算真的修好

不要只因为“不崩了”就算修复完成。至少要围绕这次的核心坏点复测：

粘贴图片后能正常生成附件，或被明确拒绝
composer 不再出现超大 base64 文本
发送失败后，草稿状态仍能正确恢复
出错后的附件恢复行为保持一致

常见判断问题 FAQ

如果输入框里已经灌进一大段 base64 文本，第一步该做什么？

第一步不是继续点发送试试，而是先把它当成 粘贴链路故障现场 保护起来。

更稳妥的处理顺序是：

先停止继续编辑这条草稿
记录这是“图片粘贴变成 base64 文本”而不是普通长 prompt
再决定是否清空、重开 composer，或者改走附件替代路径

因为一旦继续在这段内容上叠加编辑，后面会更难区分到底是 paste path 出错，还是 send / restore 逻辑又被污染了。

什么时候更该把问题归到 paste handling，而不是模型或 provider？

如果只有“粘贴图片”会触发异常，而常规文本输入、普通发送、甚至文件附件都还正常，那就更该优先归到 Control UI 的 paste handling。

这时最危险的误判就是把它扯到模型、provider 或 token 限额上，结果把排障面越拉越大。

搜 `data:image base64 pasted into composer` 的人，页面最该先帮他分哪三个支路？

最该先分这三个支路：

只有 clipboard paste 坏，还是所有附件方式都坏
当前是源码环境，还是只能改 dist bundle 的安装环境
发送失败后的草稿恢复逻辑有没有一起异常

这三步最能决定你该先做低风险绕过，还是已经需要升级到更深层 send pipeline 排查。

怎样快速区分这是超大 base64 被粘进输入框，而不是模型或 provider 自己故障？

先看最早发生变化的是哪一层。

如果下面这些现象同时成立，就更像是 paste path 故障：

异常恰好发生在粘贴图片之后
在任何模型调用成功或失败之前，composer 就已经被 data:image/...;base64,... 灌满
普通文本提问仍然可以正常发送
文件附件或非粘贴路径的表现，和剪贴板图片粘贴明显不同

这种顺序更该先怀疑 Control UI 输入链路，而不是模型不稳定、provider 拒绝，或 token 限额本身。

修完图片粘贴膨胀问题后，最该先核对什么？

别只看到“输入框干净了”就算完工。

无论是补丁还是 workaround，落地后最好立刻核对：

再次粘贴图片时，不会再把原始 base64 文本直接塞进 composer
预期的附件路径仍然可用，或者 UI 至少会干净地拒绝粘贴，而不是污染草稿
普通文本发送行为与修复前保持一致
发送失败后的草稿恢复，仍然能保住正确的文本和附件状态
这次 workaround 没有悄悄把编译产物里的其他发送路径一起带坏

最后一项很关键，因为这个问题本来就卡在 send 与 restore 的边界上，表面 UI 补丁很容易顺手制造更深层回归。

修补粘贴路径前的证据清单

不要一上来就把它归类成普通 composer bug。先补够证据，把剪贴板处理、附件路由、草稿恢复三层分开：

剪贴板来源：记录图片来自截图工具、浏览器复制、本地文件预览，还是另一个聊天应用。
payload 形态：确认 composer 里出现的是可见的 data:image/...;base64 长文本、附件对象，还是两者同时出现。
草稿恢复边界：测试发送失败、刷新或重试后，是否会再次插入同一段污染 payload。
安装包版本：带上 Control UI bundle 或 OpenClaw 版本，因为安装版 UI 修复可能落后于源码。
安全复现素材：准备一张不含隐私的小图，方便 reviewer 复现，不要依赖私人截图。

这份清单能让高意图运维快速证明问题到底在 paste interception、upload conversion，还是 composer state recovery。

如果你是从 troubleshooting 流量进来，先分清粘贴污染、模型失败和上传失败

这篇现在和 setup、troubleshooting、其他运维 bug 页出现在同一组 GA4 线索里。读者大概率只知道“图片输入坏了”，但还没确认问题发生在上传、composer 粘贴处理，还是后面的模型调用。

改 UI 代码或 provider 配置前，先按三类分流：

图片从未变成文件或预览：先查浏览器权限、上传大小限制、存储和上传 API，base64 灌入 composer 可能不是第一故障点。
输入框被巨大 data:image/...base64 字符串填满：立刻停止提交，保留 payload 大小和浏览器路径，再按本文的绕过方案处理。
图片预览正常，但模型调用失败：转去 provider key 或模型能力排障，不要先补粘贴路径。

这能让从泛排障搜索进来的高意图用户，避免修错层，把 UI 粘贴污染和后端模型失败分开处理。

从搜索进来后的 3 分钟判断：剪贴板、上传，还是草稿恢复

如果你是通过 data:image base64 composer、paste image huge text 或“粘贴截图后输入框爆炸”搜到这里，先不要改 provider 或重启 gateway。用 3 分钟定位是哪一层在污染输入：

只在剪贴板粘贴时发生：优先查 paste event interception、clipboard MIME 类型和图片到附件的转换逻辑。
拖拽或文件选择也失败：把排障面转向 upload API、文件大小限制、存储权限或附件状态，而不是只修 paste handler。
发送失败后污染又回来：重点查 draft restore、composer state serialization 和 retry path，避免补丁只挡住第一次粘贴。
只有安装版 UI 复现，源码环境不复现：记录 bundle 版本和构建时间，确认是不是 packaged UI 落后于源码修复。

这个分流能把高意图图片输入流量更快导向正确修复点：剪贴板入口、上传链路、草稿恢复，或安装包版本差异。

Sources

社区 bug 报告： openclaw/openclaw#62604

如果你是从中文首页或迁移/安装页跳过来的

GA4 现在把这篇图片粘贴问题页放进中文入口的小流量簇里。先确认你遇到的是 Control UI 粘贴图片导致 composer 被大段 base64 文本污染，而不是安装、迁移或 CLI 运行慢。

页面能打开，但粘贴截图后输入框瞬间塞满长文本：继续留在本页，优先收集浏览器、图片大小、粘贴路径和是否经过剪贴板压缩。
刚装完 OpenClaw，Web UI 或 Gateway 还没跑通：回到 Mac 安装指南或安装成功检查清单，不要把安装失败当成粘贴 bug。
从 Moltbot 迁移后路径、命令或旧配置混乱：先看 1 分钟迁移指南，再回来复现图片粘贴。

这个分流能减少误报：安装/迁移问题先排掉，真正的 Control UI 图片粘贴污染才留在本页处理。