问题
#1251 （7fd6fdcc9）已经给 OpenCode 加上 maxInitialPromptArgBytes: 8192，修好了 #1250 报的 command too long。但同一个成因在另外几个适配器上依然成立 ——它们同样把首轮内容烘进启动 argv，却都没有声明预算。
在最新 master（fd7c588ce）上枚举「argv 传首轮」的适配器，共 6 个：
适配器
maxInitialPromptArgBytes兜底
典型新话题 argv
opencode8192 （#1251 已修）—
5414 B
pi未声明
✅ 自带 PI_INITIAL_PROMPT_ARG_BYTE_LIMIT = 4096，超限转 @file
5921 B
gemini❌ 无
❌ 无
5789 B
cursor❌ 无
❌ 无
5795 B
mtr❌ 无
❌ 无
5833 B
grok❌ 无
❌ 无（见下方说明，且预算也盖不住它）
5106 B
gemini / cursor / mtr 三个是完全没有保护 的：首轮信封（buildNewTopicPrompt）本身就占 ~5.8 KB，用户消息是净增 在这之上的。
可达性（实测，非推断）
tmux backend 不按 cliId 做限制 ，这几个适配器都能跑在上面；启动命令确实整条交给 tmux new-session（src/adapters/backend/tmux-backend.ts）。
本机 tmux 3.3a 实测上限，二分到 16256 B ~ 16384 B 之间 （8 KB / 12 KB 通过，16 KB 起 command too long，与 fix(opencode): 长首轮提示词触发 tmux command too long #1250
⟹ gemini / cursor / mtr 的用户消息余量约 10.4 KB 。
触发难度 ：不是日常打字能达到的，但贴一段日志、堆栈、报错全文或一段代码就够 ——这正是 #1250 现场的形态。属于潜在但可达 ，不紧急。
⚠️ grok 要单独说：预算契约盖不住它grok 声明了 injectsSessionContext: true，路由/身份信息不走位置参数，而是走 --rules--append-system-prompt 的同类）。实测：
完整 argv 5106 B，其中 --rules 负载 4990 B
把首轮 prompt 整个拿掉之后，argv 仍有 5019 B —— 这是不可压缩的地板。
而 maxInitialPromptArgBytes 的语义只覆盖被 defer 的那个 prompt （见 shouldDeferInitialPromptForArgLimit），管不到 --rules 。所以给 grok 加预算只能削掉那 53 B 的一半，几乎没用。grok 若要治，得单独讨论 --rules 负载怎么办（同理可能波及其他 injectsSessionContext 适配器），建议不要和下面的修一起做 。
建议
给 gemini / cursor / mtr 声明 maxInitialPromptArgBytes ，复用 fix(opencode): 限制首轮 prompt argv 字节数，防止 tmux command too long #1251 回归测试 建议照抄 fix(opencode): 限制首轮 prompt argv 字节数，防止 tmux command too long #1251 buildNewTopicPrompt 构造信封（而不是手搓 fixture），这样将来谁把信封地板顶过预算，测试会真的红 。pi 已有自己的 4096 兜底，不需要改 ；grok 见上，单独立项。
备注
问题
#1251（
7fd6fdcc9）已经给 OpenCode 加上maxInitialPromptArgBytes: 8192，修好了 #1250 报的command too long。但同一个成因在另外几个适配器上依然成立——它们同样把首轮内容烘进启动 argv，却都没有声明预算。在最新 master（
fd7c588ce）上枚举「argv 传首轮」的适配器，共 6 个：maxInitialPromptArgBytesopencodepiPI_INITIAL_PROMPT_ARG_BYTE_LIMIT = 4096，超限转@filegeminicursormtrgrokgemini/cursor/mtr三个是完全没有保护的：首轮信封（buildNewTopicPrompt）本身就占 ~5.8 KB，用户消息是净增在这之上的。可达性（实测，非推断）
tmux new-session（src/adapters/backend/tmux-backend.ts）。command too long，与 fix(opencode): 长首轮提示词触发 tmux command too long #1250 现场一致）。gemini/cursor/mtr的用户消息余量约 10.4 KB。触发难度：不是日常打字能达到的，但贴一段日志、堆栈、报错全文或一段代码就够——这正是 #1250 现场的形态。属于潜在但可达，不紧急。
grok声明了injectsSessionContext: true，路由/身份信息不走位置参数，而是走--rules（Claude--append-system-prompt的同类）。实测：--rules负载 4990 B，位置参数（用户首轮）只有 53 B；而
maxInitialPromptArgBytes的语义只覆盖被 defer 的那个 prompt（见shouldDeferInitialPromptForArgLimit），管不到--rules。所以给 grok 加预算只能削掉那 53 B 的一半，几乎没用。grok 若要治，得单独讨论--rules负载怎么办（同理可能波及其他injectsSessionContext适配器），建议不要和下面的修一起做。建议
gemini/cursor/mtr声明maxInitialPromptArgBytes，复用 fix(opencode): 限制首轮 prompt argv 字节数，防止 tmux command too long #1251 已经跑通的既有 worker contract，一个适配器一行，超限自动走 post-start 输入队列。预算可对齐 OpenCode 的 8192（信封地板 ~5.8 KB，留 ~10 KB 余量仍在 tmux 上限内）。buildNewTopicPrompt构造信封（而不是手搓 fixture），这样将来谁把信封地板顶过预算，测试会真的红。pi已有自己的 4096 兜底，不需要改；grok见上，单独立项。备注
--name，因此顺手核了一遍 argv 预算面；fix(traex): 使用未截断首轮内容生成标题 #1244 自身实测最坏 4809 B，安全）。以上数字均在 masterfd7c588ce上实测，最终以维护者判断为准。