[cli] --batch 静默忽略 --runtime,且错误文案把人指向对四个运行时永远无解的 --preset

[vansin]

现象

在干净容器里(hub 已起、已登录、非 root):

anet node create oc1 --runtime opencode-cli --batch
→ [anet] ⚠ Vendor selector unavailable: User force closed the prompt with 0 null
  [anet] vendor selector 不可用(非交互终端?用 --preset <model-id> 指定)
→ 节点未创建

改用提示里给的出路也不通:

printf 'opencode-cli\n' | anet node create oc1 --batch --preset __custom__
→ Runtime (claude-agent-sdk / codex-sdk / claude-code-cli) [claude-agent-sdk]:
  ← 列表里没有 opencode-cli

源码上的原因(不是猜)

node create 有两条路径,它们对 --runtime 的处理不一致:

路径	位置	是否消费 --runtime
通用 create	cli.ts:2883 runtimeForExecution(opts.runtime, "create node")	✅ 消费
--batch 向导	createBatchWizardCommand()(cli.ts:12231)	❌ 不看 --runtime

--batch 分支里 runtime 完全来自 preset / vendor 选择(cli.ts:12300-12326):

} else if (opts.preset) {
  const sel = findVendorByModel(opts.preset) || resolveVendorSelection(opts.preset);
  runtime = sel.runtime;            // ← runtime 由 vendor 决定
} else {
  const sel = await selectVendorAndModel();   // ← 非 TTY 必失败

所以 --batch 与 --runtime 对 opencode-cli 事实上互斥:
加了 --batch 就被路由到只认 preset 的向导,而(据我所查)没有任何 vendor preset 映射到 opencode-cli。

影响

• 自动化 / CI 覆盖不了 opencode-cli 的创建路径。 这大概也是 [ci] complete agent-network unit domain still has no aggregate CI signal (OpenCode pair itself fixed) #745 那个配对 pin
  漂移长期没被测试抓到的原因之一 —— 没有测试能非交互地把这个运行时创建出来。
• 脚本化部署 opencode-cli 节点会卡在这里。

我没有验证的部分(不要当成已确认)

• 不加 --batch、只给 --runtime opencode-cli 在非 TTY 下能否成功 —— 我没测。
  源码看是路径 A(消费 --runtime),但那条路后面可能还有别的交互点。
• 是否存在我没找到的 preset / flag 能选到 opencode-cli。
  我查了 vendor 解析相关文件,没找到映射,但没有穷尽。

如果上面任一条其实可行,这条 issue 应当降级为文档问题(提示文案把人指向了走不通的 --preset)。

[vansin]

把我标注「没穷尽」的那条查穷尽了 —— 结论比原描述范围更大

原 issue 里我写:「是否存在我没找到的 preset / flag 能选到 opencode-cli……没有穷尽」。
现在穷尽了。

VENDORS 表只能产出三种 runtime

cli.ts:3470 的 const VENDORS: Vendor[],枚举其全部 runtime: 字段:

9 × runtime: "claude-agent-sdk"
2 × runtime: "claude-code-cli"
1 × runtime: "codex-sdk"

而 --batch 向导的 runtime 只来自这张表(findVendorByModel / resolveVendorSelection /
selectVendorAndModel 三个入口全部读它)。在表内检索:

opencode-cli       命中 0
grok-build-acp     命中 0
grok-build-cli     命中 0
codex-app-server   命中 0

所以不可达的是四个运行时,不止 opencode-cli

路径	可达运行时
通用 create(--runtime,cli.ts:2883 → runtimeForExecution → normalizeRuntimeStrict)	全部规范运行时
--batch 向导	仅 claude-agent-sdk / claude-code-cli / codex-sdk

opencode-cli、grok-build-acp、grok-build-cli、codex-app-server
都无法通过 --batch 非交互创建。

🔴 这条尤其影响 grok

#752 里我给 Ubuntu 24.04 用户的建议是「改用 grok-build-acp」——
而 grok-build-acp 同样不能非交互创建。也就是说我推荐的那条出路,
在脚本化/CI 场景下和原路一样走不通。这一点我当时不知道。

仍未验证的那一条(保持标注)

「不加 --batch、只给 --runtime <x> 在非 TTY 下能否成功」——
我仍然没测。源码看它走 runtimeForExecution(接受这四个),
但那条路后面可能还有别的交互点(vendor 凭据、模型选择等)。

所以本 issue 目前确凿的部分是:--batch 这条路对这四个运行时不可用;
不确凿的是:是否存在另一条非交互路径。前者已可据以行动,后者需要一次真实的非 TTY 验证。

[vansin]

🔴 更正:我这条 issue 的结论下重了

继续追下去发现 cli.ts:3886 的 usage 字符串明确支持全部七个运行时:

Usage: anet node create <node-name>
       [--runtime claude-agent-sdk|claude-code-cli|codex-sdk|codex-app-server|grok-build-acp|grok-build-cli|opencode-cli]

而 createCommand() 的路由是(cli.ts:3880):

if (!idOverride && args.includes("--batch")) {
  return await createBatchWizardCommand();     // ← 只有带 --batch 才进向导
}
const id = idOverride || args[1];
if (!id) return createInteractiveCommand();
// 否则:单节点路径 → createProfileFromOpts(id, opts) → 消费 --runtime

所以「非交互创建这四个运行时没有路径」这个说法不成立。
anet node create <name> --runtime opencode-cli(不加 --batch)走的是单节点路径,
createProfileFromOpts 是纯函数、内部零交互。

我之前的容器测试同时传了 --runtime 和 --batch,--batch 赢了,
于是我把「这组参数走不通」误当成了「这个运行时没有非交互路径」。是我用错了参数。

修正后仍然成立的部分(变窄,但仍是真缺陷)

1. --batch 静默忽略 --runtime。 用户显式传了 --runtime opencode-cli,
   它被丢掉且没有任何提示,然后掉进一个表达不了该运行时的向导。
2. 错误文案把人指向走不通的出路。 提示是「用 --preset <model-id> 指定」,
   而 VENDORS 表(cli.ts:3470)只能产出 claude-agent-sdk / claude-code-cli / codex-sdk
   —— --preset 对这四个运行时永远无解。用户会照着提示反复试。
3. 因此 --batch 多节点向导确实覆盖不到这四个运行时(这一条不变)。

建议(范围随之收窄)

• --batch 遇到 --runtime 时,要么尊重它,要么明确报错说明二者不能同用 ——
  不能静默丢弃;
• 那句提示不该无条件推荐 --preset;对 VENDORS 表覆盖不到的运行时,
  应当告诉用户「去掉 --batch,用 anet node create <name> --runtime <x>」。

对 #745 的影响

我之前说「#745 的验证被 #765 挡着」——这个说法也要收回。
既然非 batch 路径可用,那次端到端 smoke 是可以做的,只是我上次用错了参数。

仍未验证

单节点路径在非 TTY 下是否全程无交互(后面可能还有凭据/模型提示)——我没测。
这一条我不再往上加结论,留给真实验证。

[vansin]

Current-main status (2026-08-13)

The product change from #769 is now on main as 3b049160b2db542d06a32988a530f0b21f773c96:

• --batch --runtime <value> fails explicitly before entering the batch wizard;
• the selector fallback now distinguishes preset-supported runtimes from the non-batch --runtime path.

This issue remains open for one narrow reason: #769 merged with only agent-network/bin/cli.ts; its two reported container probes were not committed into a repository gate. A one-line deletion/bypass of the new conflict branch currently has no durable named behavior test tied to this issue.

Required evidence before closure remains:

1. --batch --runtime opencode-cli exits nonzero before create side effects and prints the usable non-batch command;
2. plain --batch still reaches the existing selector path;
3. deleting/bypassing the conflict guard turns the committed test red for that named reason.

This is a verification gap, not a claim that the merged product behavior is currently wrong. PR #770 is intentionally scoped to #766/#767 and does not cover this issue.

[vansin]

Closing evidence

The two previously separated parts are now both on main:

1. Product behavior — PR fix(cli): --batch 不再静默丢弃 --runtime,提示不再只推荐走不通的 --preset #769 / main 3b049160: create --batch --runtime <value> fails before creation side effects and gives a usable non-batch runtime command; plain batch retains its existing selector/fallback path.
2. Committed behavior gate — PR test(ci): pin #765 batch/runtime conflict behavior #775 / main 701d9ac0: real production CLI entry, no-node-config side-effect assertions, production build, active L1 registration, and 3/3 named witnessed-red mutations.

#775 frozen evidence:

• source f4875c23131fcfc4e63306bd7061446a8b81f8e7
• report-only head ae223f89c242990e0422a17cb7c572bd1dd1243e
• exact image sha256:ddd672f958446f4b7f15b94d2a272739b6f13126410fd8f0eecd76d292e68e00
• focused 5 pass / 0 fail
• active L1 16/16 PASS
• GitHub: all 9 checks green (E2E twice, rename-ghost twice, L0+L1, agent-node unit, three lint guards)
• independent narrow review: CLEAN, 0 BLOCKER / 0 MAJOR / 0 MINOR: test(ci): pin #765 batch/runtime conflict behavior #775 (comment)

No package publish, deployment, production config, token, or database action was part of this closure. The tracked defect and its regression gate are complete, so this issue can close.