lc code 在 registry 没有 default 时抛 TypeError traceback——#12 第三梯队给 test/e2e 修了这个，code 漏了

[github-actions]

🤖 由 issue-agent 自主提出，未经人工确认

现象

registry.json 里没有 default（或它是 null）时跑 lc code：

  File "/usr/lib/python3.12/subprocess.py", line 1885, in _execute_child
    self.pid = _fork_exec(
TypeError: expected str, bytes or os.PathLike object, not NoneType

bin/lc 的 cmd_code()：

profile = reg.get("default")
sys.exit(subprocess.call(["codex", "--profile", profile] + list(argv), env=codex_env()))

None 一路传进 subprocess.call，在 fork 那一层炸掉。

本地复现（4 步，不需要 docker / 网络 / 真模型）：造一个有 upstream 但没有 default 键的 registry.json，跑 lc sync，起一个对 /health 回 200 的假网关让 gw_alive 通过，然后 lc code。

为什么是问题

这正是 #12 第三梯队修过的那个形态——只是当时修的是 test / e2e。_targets() 的 docstring 写得很清楚：

没有默认上游时 reg.get("default") 是 None，原来会一路传进 subprocess，以 TypeError: expected str ... not NoneType 的 traceback 收场。

_targets() 现在被 cmd_test 和 cmd_e2e 调用，cmd_code 没有走这条路，于是同一个 bug 在 lc code 上原样留着。test-lc-commands.sh 里有 ✅ lc e2e 没有 TypeError 这条断言，但 code 没有对应的一条。

后果不严重（不泄密、不误连），但踩到的人恰好是最不该被 traceback 招待的那个：刚 lc rm 掉当前默认上游、或手工编辑过 registry.json 的新手。项目在别处对这类分支的要求一直是「给一句人话，不是 Python 栈」。

顺带，lc rm 删掉默认上游之后是否会重新指定 default，值得一并核一下——那可能就是走到这个状态最常见的路径。

建议怎么做

cmd_code 里在 gw_alive 检查之后加：

profile = reg.get("default")
if not profile:
    die("没有默认上游，用 `lc use <name>` 选一个。可用: %s" % ", ".join(sorted(reg.get("upstreams") or {})))

上游表为空时应当指向 lc init 而不是 lc use，和 _targets() 的措辞对齐；能否直接复用 _targets() 需要看一下——它返回的是列表，而 code 只要一个，可能包一层更干净。

完成标准：test-lc-commands.sh 的 [6] 里加两条（假网关和假 codex 桩都已经就位）：

1. 无 default 时 lc code 非零退出、输出里没有 Traceback、并指向 lc use
2. 此时压根没启动 Codex（[6a] 已经有这个形态的断言可以照抄）

取舍

这条我看不出真正的取舍——就是一个漏网的输入校验，和 #12 第三梯队已经接受过的修法完全一致。唯一要定的是措辞（指向 lc use 还是 lc init），而这个照抄 _targets() 即可。

如果你觉得不值得单开一个 issue，直接关掉就是；我提出来是因为它有明确的完成标准和现成的门禁位置，不属于「代码可以更优雅」那一类。

来源

修 #42 时读 cmd_code 发现的。那个 PR 只动环境变量注入，没有夹带这个修复。

[LouisDM]

已 approve。复现确认。

复现

registry.json 里 default: null、网关活着时：

TypeError: expected str, bytes or os.PathLike object, not NoneType
  File "bin/lc", line 780, in cmd_code
    sys.exit(subprocess.call(["codex", "--profile", profile] + list(argv), ...

reg.get("default") 返回 None，直接进了 subprocess.call 的参数列表。

注意先决条件是网关活着——网关没起时被 die("网关没起来") 提前短路，所以这条只在「网关正常但 registry 没有默认上游」时暴露。这个状态不难达到：lc rm 掉最后一个上游（cmd_rm 会把 default 置回 None）之后，网关还在跑着。

为什么值得修

这个项目一路在消灭 traceback——smoke.py 的配置缺失、lc status 的网关不可达、lc doctor 的非 JSON 响应，都专门做过「给一句干净的话，不是 traceback」。这里漏了一个，而且吐的是 subprocess 内部的堆栈，读的人完全看不出根因是「没有默认上游」。

修法

cmd_code 在用 profile 之前校验，die 一句可操作的话。参考 test-codex.sh 里那个防呆的措辞——它会把可用的 profile 列出来：

❌ registry 里没有默认上游
   可用: <列出来>；用 `lc use <name>` 选一个
   一个都没有的话先 `lc add`

顺带扫一遍同类

reg.get("default") 不止这一处。cmd_e2e、gen_codex 里也读它，值得一起看看在 None 时的行为是否都干净。如果发现别处也会炸，一并修在这个 PR 里——同一个根因不必拆开。

测试

test-lc-commands.sh 的 code 分支补一条：default 为 null + 桩网关活着时，退出码非零且输出里没有 Traceback。

第二条断言比第一条重要：「非零退出」很容易靠 traceback 满足，Traceback 不出现才是这个 issue 的不变量。

[github-actions]

🤖 由 issue-agent 自动发布

已在 #48 修复并合并（CI static + docker 全绿）。

根因

cmd_code 里 reg.get("default") 的 None 直接进了 subprocess.call 的参数
列表。_targets() 的那三条校验只覆盖 lc test / lc e2e，lc code 不走那条路。

先决条件确认了是网关活着——网关没起时被 die("网关没起来") 提前短路。

改法

新增 _default_target(reg)，cmd_code 用它取 profile。没直接复用 _targets()：
那个函数把 argv 当上游名解析，而 lc code 的 argv 是要透传给 Codex 的参数
（--sandbox read-only 之类），传进去会被当成上游名挡下来。失败措辞与
_targets() 对齐：空注册表 → lc init，有上游没选默认 → lc use <name> 并
列出可用的。

按「顺带扫一遍同类」的要求扫过其余读 default 的地方：

• cmd_e2e 走 _targets()，已经干净。
• gen_codex 在 default 为 None 时回落到排序后的第一个上游，只影响生成
  配置里的顶层 model =，不会传进 subprocess，未改动。
• 多挡下一条：default 指向一个已经不存在的上游（手改 registry 之后）。
  它不会炸，但后果更坏——Codex 对不存在的 profile 是静默回落到默认 model 的，
  正是本项目在别处一直当作缺陷处理的那个形态。

门禁

scripts/test-lc-commands.sh 新增 [6f] / [6g]（放在网关桩还活着的位置，
那正是这条 bug 的先决条件）：

• default: null → 非零退出 / 无 Traceback / 无 TypeError / 说「没有
  默认上游」/ 指向 lc use <name> / 列出 alpha, beta / 压根没启动 Codex
• default: "ghost" → 点名失效的默认上游，且没拿不存在的 profile 去启动 Codex
• upstreams: {} → 指向 lc init，且不建议 lc use

按你说的，「无 TypeError」比「非零退出」重要——后者一段 traceback 也能满足。

反向验证过：把那一行改回 profile = reg.get("default")，新增断言 9 条变红，
其中包括 argv=--profile ghost 那条（证明失效 default 真的会把不存在的
profile 递给 Codex）。这些断言随 bash scripts/test-lc-commands.sh 进 static
job，没有改 .github/。