Codex CLI 多行粘贴只发第一行？输入与送出验证

复制了一整段问题到 Codex CLI，却发现它已经开始回答第一行，剩下的清单还留在输入框。另一种情况是长文本变成了 [Pasted Content … chars]，让人担心正文消失了。先确认粘贴是否提前触发发送，再检查整段文字是否属于同一条消息；占位显示本身不能证明内容丢失。

本文处理 codex cli multiline paste submits first line、长提示词粘贴后自动发送等输入问题。图片没有附上请看图片输入排查；已经生成的回答翻不到，请看终端回看与 tmux。

先看发生在哪一层

现象	先做什么	不能直接判定
粘完就开始回答，自己没另外按 Enter	保留已发消息与剩余草稿，做第 2 步对照	网络故障，或模型故意漏读
草稿显示 `Pasted Content` 一类占位	按第 3、5 步核对内容	占位符就是实际发出的全部文字
手打文字时按换行键却发送	看当前按键绑定、终端与输入法	与多行粘贴一定是同一个原因
桌面或 IDE 把长文本变成 `.txt` 附件	核对该客户端的附件及本条消息	CLI 的终端粘贴机制也适用
输入完全无变化	确认焦点、终端粘贴入口与执行端	Codex 不支持多行文本

1. 保存未发内容，记清真正的输入链路

适用条件： 正在处理一段不能丢的提示词，或已经误发了半条消息。

先把剩余草稿保存到有权限访问的本地编辑器；不要为了测试清空唯一副本。若半条消息已让代理开始工作，查看它实际执行到哪里，按客户端正常方式停止这次不完整任务，再审查文件状态。停止响应不代表先前改动自动撤销；需要保全与还原时看保留原有修改的撤销边界。

在启动该 CLI 的同一终端检查：

codex --version
codex --help

记录终端名称与版本、操作系统、是否经过 tmux、SSH、WSL 或 IDE 集成终端，以及实际粘贴入口。桌面聊天输入框、桌面内嵌终端与终端里的 Codex CLI 是不同输入层。

预期结果： 能写出类似“Windows Terminal → PowerShell → Codex CLI”的完整链路。版本不符先查安装来源与实际版本，不要拿另一端的版本解释当前行为。

2. 用无敏感内容的小样例，检查是否提前发送

适用条件： 要确认问题发生在粘贴阶段，尚不需要让模型改代码。

在独立、无敏感内容的测试会话中，用正常终端粘贴入口贴入下列固定文字。先不要额外按发送键，观察草稿与消息区。

只做输入核对，不运行命令、不修改文件。
BEGIN_A17
中间_B28
END_C39

预期结果： 整段留在草稿中，尚未产生新的已发消息或回复。实际显示可以折叠，不要求每一行同时铺开。

如果没按发送键就出现了新消息，记下它包含几行，剩余几行是否仍在草稿；这已经是有效的输入故障证据，不必用真实代码和长日志反复重现。测试会话仍可能自动发起请求并使用额度，应保持一次小样例。

需要对照时，仅把首行改成纯英文，再使用相同终端、版本和粘贴方式试一次。结果不同只说明这组输入条件存在差异，不能据此锁定输入法、终端或 CLI 的统一根因。手打输入法选字、逐行键入、整段粘贴也不要混为一次测试。

3. 长文本变成占位，先核内容再决定是否修复

适用条件： 只有折叠显示，尚未观察到提前发送或明确缺字。

Pasted Content 一类标记可能只是 CLI 对长文本的显示方式。本次核验版本中，1,985 字符的合成多行提示词显示为 [Pasted Content 1985 chars]，明确发送后，隔离接收端仍取得整段文字。这个长度是测试样例，不是产品的固定折叠阈值。

对自己的输入，保留编辑器里的原文，核对它是否进入了本次草稿或已发消息；当前界面支持查看或编辑折叠内容时再使用该入口。不要照搬其他版本的按键，也不要直接把占位文本替换成空白。

如果当前界面无法展开或核对，就记录“草稿正文未完全核对”，转第 4 步用外部编辑器确认输入。桌面或 IDE 的 .txt 附件要按其实际附件入口核对，不能用 CLI 的折叠测试证明附件上传成功。

4. 用官方外部编辑器入口准备长提示词

适用条件： 当前 CLI 支持该入口，而且输入框处于可编辑状态；原始草稿已另存。

官方 CLI customization说明：在输入框按 Ctrl+G，打开 VISUAL 指定的编辑器；没有设置 VISUAL 时使用 EDITOR。在编辑器保存并退出后，文字返回 CLI 草稿，再由你发送。

先确认配置的是自己已有、可信且能等待编辑结束的编辑器。找不到命令、编辑器立刻退出或一直不返回，都应先按该编辑器的用法处理；不是增加模型权限的问题。
按 Ctrl+G，在编辑器中检查首行、中间清单、末尾限制和代码块，再保存并退出。
回到 CLI，确认草稿已返回且没有自动发送；然后按第 5 步核对。

macOS/Linux 的一次测试启动示例：仅在已经安装 nano、且 command -v nano 能找到它时使用。此写法只给这次进程指定编辑器，不改全局 Codex 配置；请先保存当前工作，再决定是否另开测试会话。

command -v nano
VISUAL=nano codex

Windows 则按自己的终端与已有编辑器设置 VISUAL 或 EDITOR，不要照抄 Unix 命令。没有合适编辑器时，可先把提示词保留为本地文件，并让任务明确读取经授权的同机路径；这属于文件读取路径，仍需核对实际读取记录，见文件路径与读取验证。仅发送文件名不等于正文已经成为输入。

失败去向： Ctrl+G 没有对应效果时，先看当前版本的命令帮助、焦点和 /keymap。当前官方支持自定义 TUI 按键，旧教程里的“Codex 不能改快捷键”不适合作为现行结论。只有查明当前绑定及终端是否传递该按键后，才有依据修改；不默认改终端全局快捷键或扩展程序文件。

5. 分开验收草稿、发送内容与模型执行

适用条件： 已有一条能保留完整草稿的路径，现在需要验证原来的卡点是否解决。

明确发送第 2 步小样例后，查看这条已发消息是否对应原文。若还要检查模型对本次输入的处理，可要求它只复述编号首、中、尾三项，不执行命令；将返回值与原文逐项比对。

检查结果	可以记录的结论
粘贴后没有自动发送，草稿内容可核对	本次草稿输入通过
正常发送后，本条消息内容可核对	本次界面中的已发内容通过；没有底层记录时不推断全部传输细节
回复准确对应测试中的三项	本次局部内容处理符合样例；不证明长文每一字都被使用
编辑器路径可用，原粘贴入口仍提前发送	有可用输入替代路径，原粘贴问题尚未解决
消息完整但回答仍漏要求	继续核对任务要求与执行成果，不能重新归因于剪贴板

三项都出现，仍不等于整份提示词逐字完整、所有限制都被遵守或任务真正完成。真实工作还需审查改动、测试与交付结果，见任务完成与真实成果。

当前证据与未实测范围

公开 issue #31416于 2026 年 7 月 7 日报告 Windows Terminal / PowerShell、CLI 0.142.5 的首行提前提交；后续有不同用户和版本反馈。评论中的候选补丁、重复标记与 Open 状态，不证明当前所有同类问题的根因、影响范围或修复版本，不能直接推荐下载第三方修补包。

2026 年 10 月 23 日，本次在 macOS、CLI 0.163.0-alpha.11.2、独立 PTY 与 tmux 3.7c、空 HOME/CODEX_HOME 中验证了四组情况：显式 bracketed paste 的英文 LF、中文 CRLF、长文本折叠，以及 Ctrl+G 外部编辑器返回草稿。前两者按 CRLF→LF 规范化后与隔离接收端文本一致，长文本也完整；VISUAL 优先于故意不可用的 EDITOR，返回后由明确发送动作提交。没有调用真实模型或读取用户认证、历史与配置。

这是固定本机回环回复服务的输入构造验证，没有复现 Windows 原生剪贴板、中文输入法选字、SSH 或图形终端粘贴，也不证明真实模型理解了全部内容。求助时提供脱敏版本、完整输入链路、最小文本、粘贴后与发送后的差异；不要公开真实提示词、私有日志或整份会话。