请求支持一下MiniMax code 和 MiniMax code cli #1050

Activity

1. ranxianglei commented on Sep 20, 2026

   

   ranxianglei

   on Sep 20, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   收到。目标确认一下：你说的应该是 MiniMax-AI/minimax-code（终端编码 agent，命令 mcode，npm 包 @minimax-ai/code，TypeScript 开源）——"MiniMax code" 和 "MiniMax code cli" 我理解是同一个东西（TUI + headless mcode exec + ACP），如果还指别的（比如桌面版）请补充说明。

   按仓库规范，feature 类需求先做评估再动手。我正在调研它的几个关键机制：provider/base_url 配置格式、是否尊重代理环境变量、插件系统形态（决定能不能做 native plugin）、模型请求是否带稳定会话 id、有没有需要关掉的自带 auto-compact。调研完会给出集成方案建议（launcher / native plugin / 纯 /bili/ 文档）供你拍板再实现。
2. ranxianglei commented on Sep 20, 2026

   

   ranxianglei

   on Sep 20, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   进度同步：刚才调研子任务挂起导致会话被重启。好消息是 minimax-code 源码已克隆到本地工作区，我现在直接读源码继续调研（配置格式、代理支持、插件系统、auto-compact、请求里的会话 id 等），拿到结论后给你方案建议。稍等。
3. ranxianglei commented on Sep 20, 2026

   

   ranxianglei

   on Sep 20, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   [bot] 🏷 调研完成，给出结论与建议方案：

   目标确认
   "MiniMax Code" = mcode CLI（github.com/MiniMax-AI/minimax-code，npm 包 @minimax-ai/code，当前 v0.4.12，Node ≥22.19）。已全库查重（含已关闭），无重复 issue。本方案覆盖 CLI/TUI/headless(mcode exec)；若你还指桌面版 MiniMax Code app——它源码未开源，无法做同等集成，如有需要请另开 issue 说明。

   源码核实要点（v0.4.12）

   1. 代理支持：mcode 启动早期读取标准代理环境变量（HTTPS_PROXY/HTTP_PROXY/ALL_PROXY/NO_PROXY）并应用到全部出站流量（undici 全局 dispatcher，含模型请求）——与 kimi/dsh 同类。
   2. 回环硬编码绕过：localhost/127.0.0.1/::1 无条件加入 NO_PROXY（不可配置），本地 plain-http upstream 走不了代理。
   3. TLS 信任：纯 Node 运行时，NODE_EXTRA_CA_CERTS 生效 → bili 的 cert-MITM 路线可用（同 pi/claude/kimi）。
   4. 会话标识：每个模型请求都带 X-Mavis-Session-Id 头（另有 X-Mavis-Agent-Id）→ bili 可用原生稳定 ID 绑定会话，优于内容哈希。
   5. wire 格式：登录账号（agent.minimax.io/.cn）、minimax_api API key（api.minimax.io / api.minimaxi.com /anthropic）、custom provider 默认均为 Anthropic Messages → bili 已有 anthropic adapter，无新协议工作。
   6. 插件系统：声明式事件钩子（PreToolUse/PreCompact 等事件上执行子进程命令），不能拦截或改写模型请求 → opencode/pi 式 native plugin mode（agent 自主压缩）不可行，只能走 proxy mode（同 codex/claude/kimi launchers）。
   7. 内置 auto-compaction：在接近模型 context window 时触发，阈值硬编码、无配置项可关。bili 在更低阈值先压缩的话，正常运行中 mcode 内置压缩基本不会触发；万一触发，其摘要重写历史产生的陈旧引用由 orphan-gc 兜底。实现时会实测验证。

   建议方案（推荐路径，单一推荐）
   新增 launcher bili mcode（别名 bili minimax），纯 proxy mode，完全复用现有 kimi(#757)/qoder 模式：

   • 注入 HTTPS_PROXY 等代理环境变量 + NODE_EXTRA_CA_CERTS（bili CA）+ BILLION_CONTEXT_PROXY；二进制解析：PATH 上的 mcode → ~/.minimax-code/bin/mcode；客户端参数透传（TUI/exec/acp 均覆盖）。
   • client-config.ts 只读发现 ~/.minimax/config.yaml（及 profile 目录 ~/.minimax-*）：提取 minimax_api.baseURL 与各 custom_provider 的 base_url，分类为 MITM 白名单（https 远程）/ forward-proxy（http 远程）/ 回环清单（仅提示）。
   • 默认白名单官方域：agent.minimax.io、agent.minimax.cn、agent.minimaxi.com、api.minimax.io、api.minimaxi.com。
   • 会话绑定用 X-Mavis-Session-Id。

   已知限制（与 kimi #757 相同处理）
   http://127.0.0.1:xxxx/v1 这类本地 upstream 因回环硬编码绕过代理，MITM 压不到；workaround 是在 config.yaml 里把该 provider 的 base_url 手动加 /bili/ 前缀（launcher 检测到只警告提示，不代改用户配置）。远程 HTTPS upstream（官方端点、远程网关）开箱即用。

   改动范围：src/launcher.ts + src/client-config.ts + src/server.ts（session header 识别）+ 测试 + README/CONFIGURATION 中英文档。若你确认这个范围（proxy-mode launcher only），我就开工。
4. ranxianglei commented on Sep 20, 2026

   

   ranxianglei

   on Sep 20, 2026

   Owner

   More actions

   优先bili 启动器,不要搞别名,就是bili 后跟着原来命令.

   最好有native模式 如果可以

   🚀React with 🚀1Reacted by ranxianglei
5. ranxianglei commented on Sep 20, 2026

   

   ranxianglei

   on Sep 20, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   [bot] 🏷 收到，按此开工：launcher 就叫 bili mcode（无别名），proxy mode。

   native 模式我再从三个角度复核了一遍，结论是目前不可行：

   1. mcode 的插件系统是声明式事件钩子（PreToolUse/PreCompact 等事件上跑子进程命令），拿不到模型请求和会话历史的改写权；
   2. TUI CLI 没有 pi 式 -e <file> 进程内扩展入口（vendored 的 pi-mono 只是 AI 传输层源码依赖，不暴露扩展点）；
   3. MCP 只能注册工具、返回 tool result，无法重写会话历史——而压缩的本质就是历史重写。

   所以 native 压缩（agent 自主执行 compress）需要上游 mcode 先支持进程内扩展才能做；等它哪天加了这类机制，bili 这边补一个 agent 侧插件即可，launcher 不受影响。

   现在开始实现：src/client-config.ts（只读发现 ~/.minimax/config.yaml）+ src/launcher.ts（mcode 分支）+ src/server.ts（X-Mavis-Session-Id 会话绑定）+ 测试 + 文档，完成后提 PR。
6. ranxianglei commented on Sep 20, 2026

   

   ranxianglei

   on Sep 20, 2026

   Owner

   More actions

   🤖 Powered by ework · qwen3.8-27b

   [bot] 🏷 已按拍板实现完毕,PR:#1060

   做了什么(bili mcode,无别名):

   • 启动器(证书 MITM):mcode 走标准代理环境变量(HTTPS_PROXY + NODE_EXTRA_CA_CERTS/SSL_CERT_FILE),但源码确认它对回环地址有无条件绕过(localhost/127.0.0.1/::1 恒进 NO_PROXY)——所以非回环 https 自动进 MITM 白名单、非回环 http 走绝对形式转发;回环端点启动时编目并提示手动加 /bili/ 前缀(kimi 支持kimi code #757 同款)。
   • 配置发现:读 ~/.minimax*/config.yaml(含所有 profile 目录,遵循 MINIMAX_DATA_DIR/MAVIS_DATA_DIR),提取 minimax_api.baseURL + 各 custom_provider.*.options.baseURL 及模型窗口;未声明时默认白名单官方端点 agent.minimax.io / agent.minimax.cn / agent.minimaxi.com / api.minimax.io / api.minimaxi.com。二进制解析:PATH → <MCODE_INSTALL_DIR|~/.minimax-code>/bin/mcode(Windows 探测 .cmd/.bat/.exe)。
   • 会话绑定:mcode 每个模型请求都带 X-Mavis-Session-Id 头(源码验证),已加入 bili 的会话头识别——跨轮次、跨凭证轮换稳定。
   • native 模式不可行(维持之前结论):其插件体系是纯声明式事件钩子(SessionStart/PreToolUse/PreCompact 等子进程命令),无进程内扩展入口、无模型请求/历史改写接缝。上游若将来开放进程内扩展再补。
   • CLI help + README(中/英)+ CONFIGURATION(中/英)同步更新。

   预检(该分支 head):typecheck ✓ / test 2090 pass · 0 fail / build ✓;新增 8 个测试(YAML 解析、配置发现、路由分派、默认主机、二进制解析、runLaunch 环境变量、会话头轮换、模型窗口 scope)。diff 仅 11 个相关文件,无版本号/锁文件变动。

   一句话中文摘要:按"优先启动器、不弄别名"的要求新增了 bili mcode 启动器(MiniMax Code 证书 MITM 代理 + config.yaml 主机发现 + X-Mavis-Session-Id 会话绑定),native 模式因上游插件体系无进程内接缝而暂不可行,可以合并。
7. ranxianglei

   added 2 commits that reference this issue on Sep 20, 2026

   feat: add mcode (MiniMax Code) launcher (#1050)

   21d27cd

   feat: add mcode (MiniMax Code) launcher (#1050)

   60732fe
8. ranxianglei

   closed this as completedin #1060on Sep 20, 2026
9. ranxianglei

   added a commit that references this issue on Sep 26, 2026

   refactor: complete mcode conversion to applyLoopbackBypassMitmEnv (#1440

   ...

   1b87b17