feat: launcher-first UX — native-plugin experience with zero persistent host config (plugin-in-launcher, 内外呼应)

[ranxianglei]

Vision

Proxy 版在大多数场景下直接可用；native 适配只剩极少数宿主（omp 这类有 in-process hook 的）。
launcher 把所有"需要碰宿主"的动作收敛为 spawn 参数 —— 用户只换一个启动命令（bili claude / bili codex），体验与本地插件版几乎无差别，宿主配置文件零写入、已有插件零影响、卸载零残留。

这是 dog/billion-context#1（内外呼应）的 launcher 化延伸：插件不再要求用户"安装"，而是由 launcher 注入。

Why launcher is the answer

插件层（MCP/hooks）在 Claude Code/Codex 里够不着 provider 请求（hooks 是通知型、MCP 是子进程工具提供方）。谁能看见 wire，谁才有资格当引擎 —— 这两个宿主的引擎必须在 proxy。launcher = spawn 时刻的上帝视角，把铺管（流量出口）、工具注册（MCP flag）、会话钩子全部转成 CLI 参数。

Verified: merge semantics are additive（本机官方 --help 实证）

机制	语义	已有插件
claude --settings <file-or-json>	help 原文 "load additional settings from" —— 分层叠加，hooks 跨层并集	✅ 不受影响
claude --mcp-config <file>	追加 server 列表（与 ~/.claude.json 并存）	✅
codex -c mcp_servers.bili.command=...	TOML 单键覆盖，只碰 bili 子表	✅
磁盘	launcher 只传 flag + 随用随弃临时 JSON	✅ 零写入

冲突面只剩同 key 碰撞 → 命名纪律：server 名固定 bili；settings 文件只含 env.ANTHROPIC_BASE_URL + 自有 hook 条目；codex 只动 mcp_servers.bili.* 前缀。

Topology: 一个 loopback 端口，三条信道

bili claude / bili codex（launcher）
  ├─ ensure proxy 单例（spawn/复用 127.0.0.1:8787）
  ├─ spawn env: BASE_URL /（MITM 场景才需要 CA）
  └─ CLI flags: --mcp-config / --settings / -c mcp_servers.bili.*
        ↓ exec 宿主
host（claude/codex）
  ├─ LLM 流量      → proxy（数据信道）
  ├─ MCP bili      → POST /__bili/plugin/tool（工具执行，#161 端点原样复用，body 带 conversationId）
  └─ SessionStart  → POST /__bili/plugin/register（会话身份，仅 CC；先于首次 LLM 调用）

Degradation ladder（不装 MCP 壳也完全可用）

1. launcher + MCP 注入（目标态）：原生工具 UX/权限/审计；CC 会话身份=真 session_id
2. launcher 仅铺管：proxy wire 注入工具（现状）—— 已有插件同样零影响
3. 手动配置：现有 README 路径，兜底

MVP scope

• launcher 升级：claude 走 ANTHROPIC_BASE_URL（去 MITM，直连 URL 模式）+ --mcp-config + --settings（hooks）；codex 走 openai_base_url + -c mcp_servers.bili.*
• proxy: POST /__bili/plugin/register {conversationId}（SessionStart → 预关联指纹；feat: cooperative plugin protocol — agent-side native tools + proxy-owned engine #161 conversation LRU 已有底座）
• MCP 薄壳：单 server（stdio），GET manifest → 暴露 4 工具 → POST /tool 转发（可并入本仓 billion-context 的 bin，或独立 billion-context-mcp）
• 待验证①：--settings 注入 SessionStart hook 端到端真触发（flag 存在已证，行为待 e2e）
• 待验证②：codex -c 内联表 mcp_servers.* 语法（-c 'mcp_servers.bili.command="..."'）实测
• 文档：launcher 模式 vs 手动模式矩阵

Non-goals

• 不持久写宿主配置文件（永远只走 flag/env）
• launcher 直连 URL 模式不引入 MITM/CA（CC OAuth 订阅场景保留 MITM 兜底）
• 不替代 omp native 模式（纯内仍是 omp 的最优解）

Relation

• 依赖 feat: cooperative plugin protocol — agent-side native tools + proxy-owned engine #161（plugin protocol：manifest / tool 端点 / conversation LRU）与 refactor: adopt acp-kernel/wire — codecs move to the kernel #160（wire 上游化）
• launcher.ts 现有 663 行是底座（bili pi/codex/claude 已存在，MITM 路线）——本设计是升级而非重写

Strategic note

om/omp 类宿主 = 引擎进程内（native 插件，已覆盖）；其余一切能改 base URL 或能被 spawn 包裹的客户端 = proxy + launcher。特殊 native 适配只剩"既无插件能力又不能改出口"的 exotic 客户端。

[ranxianglei]

#162 MVP 完成 → PR #163（叠在 #161 上）

交付

• POST /__bili/plugin/register {conversationId, agent, identity} + 双绑定策略
• bili mcp MCP stdio 薄壳（manifest → 4 工具 → /tool 转发）
• bili plugin-register CLI 兜底
• launcher 直连 URL 模式（claude env + --mcp-config 临时 JSON；codex -c mcp_servers.bili.*），宿主配置零写入
• BILI_LAUNCHER_PLUGIN=0 / BILI_LAUNCHER_MITM=1 两个逃生口

两个待验证项的结论

• ①SessionStart hook：不再需要。实测 claude 2.1.227 给 MCP 子进程传 CLAUDE_CODE_SESSION_ID 环境变量，且每个 LLM 请求带 x-claude-code-session-id 头（两者相等，raw socket 抓包证实）。身份驱动绑定天然免竞态 —— 比 hook 更简单可靠。
• ②codex -c 内联表：语法被 0.147 接受（配置解析通过）。完整 LLM e2e 缺 Responses 上游未能走通（本地 glm-proxy 只有 chat/completions），MCP/注入面已独立验证。

真机证据

bili claude -p "call the bili acp_status tool" → proxy 日志 [plugin] tool acp_status executed via plugin（原生 MCP 路径，wire 注入被抑制），450/450 测试，CI 全绿。

一个设计要点：identity 与 headless 双模式分开（claude 身份绑定 / codex 无头 pending），避免外来会话误吞注册 —— 测试覆盖了该泄漏场景。