DSH Connect MiniMax Code

DSH Connect MiniMax Code (dsh-connect-minimaxcode)

把本机已登录的 MiniMax Code 桌面 App（国内版） 的模型接入 DeepSeek Harness（DSH），装好即用，无需配置 API Key。

English | 简体中文

灵感来源

本插件的思路来自 corrinehu/dsh-workbuddy-connect（作者 Corrine Hu）。

它最早证明了这样一件事：桌面 App 已经登录的模型，可以零配置地搬进 DSH——不去碰账号密码，不引入新的鉴权体系，只是把本机已有的登录态接上一个 provider，并复用 DSH 自带的 provider 适配器。本插件把同一套做法用在了 MiniMax Code 上：

· dsh-workbuddy-connect · 本插件 数据来源 · WorkBuddy 桌面 App 的本地登录态 · MiniMax Code 桌面 App 的本地登录态 接入方式 · 注册 DSH provider，暴露已登录模型 · 同左 目录来源 · 上游实时模型列表 · 同左

同方向的另一实现是 dingminhua/dsh-connect-workbuddy，本插件在插件结构与 provider 注册的组织方式上参考了同一作者的 dsh-connect-trae（该项目的连接内核本身也参照了 corrinehu 的实现，见其 README 致谢）。

两者的价值可以这样区分：corrinehu 是最早的开创者，「复用本机登录态」的路线由它确立；dingminhua 的实现更贴近 DSH 插件结构的既有约定，本插件的目录布局与 cordis.patch.yml 写法沿用了后者。二者都已列入文末致谢。

⚠️ 重要声明（请先阅读）

• 本项目仅供学习与研究使用，不面向生产环境，也不提供任何商业支持。
• 本项目为非官方插件，与 MiniMax、DeepSeek 均无关联，未获其认可或授权。
• 本插件仅读取你自己本机上 MiniMax Code 已登录的凭证，仅驱动你自己的账号在你自己的电脑上调用。
• 禁止将本插件用于商业用途、超出个人合理使用范围的场景，或任何批量/多账号/规避限额的目的。
• 本插件依赖 MiniMax 客户端的非公开接口。MiniMax 更新客户端后，接口可能变更导致插件失效。
• 使用者需自行遵守 MiniMax 的服务条款。因使用本插件产生的一切后果（账号受限、额度清空、服务中断等）由使用者自行承担。
• 本项目作者不对任何因使用或不当使用本插件造成的直接或间接损失负责。

特点

• 零配置：自动读取 MiniMax Code 桌面 App 的登录态，不在 DSH 中存储任何明文 Token
• 动态模型目录：从上游接口实时拉取，模型增减无需更新插件
• 积分余额可见：在输入框工具行（模型选择器旁）的胶囊里显示 MiniMax Code 的剩余积分，以及本机累计消耗
• 实时消耗统计：每次请求的 token 用量取自上游响应本身，可按官方价目表折算等效金额
• 复用官方适配器：上游为标准 Anthropic Messages 协议，直接复用 DSH 自带 provider，工具调用、推理块、上下文压缩均由 DSH 托管
• 不用装桌面 App 也能用：插件可以自己走 OAuth 设备码流登录，你在自己的浏览器里确认即可，插件从不接触密码
• 每日签到：MiniMax Code 每天送积分，客户端不会自动领；插件可以显示七天一签的进度，并代领当天的额度
• 只读为主：除「续期已过期的桌面 App 登录态」和「你自己发起的登录」外，不写入、不修改 MiniMax 的任何文件
• 跟随所选模型：余额显示在输入框工具行（模型选择器旁），且只在选中 MiniMax 模型时出现 —— 切到其他反代插件的模型就整体隐藏，不会拿着 MiniMax 的余额误导你
• 插件页有自己的图标与中英文：随包发布一张 48×48 的 SVG，插件页不再显示默认占位图；标题与简介按宿主语言给中英文两版，界面文案也跟着宿主语言走
• 能看图：模型目录里声明了 image 输入模态的模型（M3、M3.1-Flash）可以直接发图；图片由宿主的附件服务读成请求字节，插件只负责把持久化的附件引用接上去

前置条件

二选一：

1. 已安装并登录 MiniMax Code 桌面 App（国内版） —— 插件直接复用它的登录态（最省事）
2. 什么都不装 —— 在插件页面点「登录 MiniMax Code」，插件发起 OAuth 设备码流，你在浏览器里用自己的 MiniMax 账号确认，插件拿到自己的登录态（需要能访问 account.minimax.cn）

另外需要 DSH 桌面版（内置内核 >=0.2.1-rc.2 <0.3.0，见 package.json 的 engines.dsh；实测 0.2.1-rc.2）或 Web profile。

发图需要宿主提供附件服务：图片不是插件自己读的，而是由宿主的持久化附件服务读成请求字节，插件只负责把附件引用接上去。宿主没有附件服务时，插件照常加载、文本照常对话，只是发图会被拒绝（pi-ai image input requires the durable attachment service）。

安装

方式一：从 Git 仓库安装（推荐，拿到最新代码）

dsh plugin --profile desktop add github:JeffTsuiCUG/dsh-connect-minimaxcode

方式二：npm 安装（发布后可用）

dsh plugin --profile desktop add dsh-connect-minimaxcode

想立刻用上积分余额与到期提示，请锁版本安装 —— pnpm 11 默认 minimumReleaseAge 为 1440 分钟，新版本发布后 24 小时内不带版本号的安装会解析到较早的版本（当前会落到 0.2.x，而积分功能是 0.3.0 才有的）：

```bash

dsh plugin --profile desktop add dsh-connect-minimaxcode@0.4.2

`

Web profile 把 --profile desktop 换成 --profile web。

桌面版的 profile 由 Electron 应用独占，若 dsh 命令不在 PATH 中，请使用 DSH 应用自带的载体 CLI（路径随安装位置而变，例如 \resources\runtime\cli\bin\dsh.cmd）。

安装后插件会热加载，模型随后出现在模型选择器的 MiniMax Code 分组中。

积分胶囊与插件页面卡片属于浏览器侧插件，首次安装、或升级到 0.3.0 及之后的版本后，需要重启一次 DSH 才会出现（模型通路本身不需要重启）。

若安装被 allowBuilds 拦截

本仓库把构建产物 lib/ 一并提交，因此正常情况下安装不会触发构建。若你看到：

[ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED] Failed to prepare git-hosted package

说明你使用的是某个早于 `0.2.1` 的提交（那些版本尚未提交 lib/）。解决办法二选一：

• 改用上面写法指定版本：github:JeffTsuiCUG/dsh-connect-minimaxcode#v0.2.1
• 或在该 profile 的 pnpm-workspace.yaml 中加入 pnpm 提示的 allowBuilds 条目后重试

使用流程

1. 确认桌面 App 已登录

打开 MiniMax Code 桌面 App，确认处于已登录状态。插件读取的是 App 写入的本地登录态。

1. 安装插件（见上一步的命令），等待热加载完成。
2. 选择模型

打开 DSH 的模型选择器，在 MiniMax Code 分组下选择模型。可用模型来自上游实时目录，例如 M3、M3.1-Flash。

1. 正常对话

直接使用即可。工具调用由 DSH 本地工具执行，插件只负责提供模型通路。

1. 令牌过期时重新登录

MiniMax Code 有两份互不通用的登录态，本插件各用其一：

凭证 · 位置 · 有效期 · 用途 JWT · ~/.minimax/local-runtime.auth.json · 约 15 天 · 调模型网关（/mavis/api/v1/llm/v1/messages） OAuth（mmoat_） · ~/.minimax/auth/prod//mcode-public/auth.json · 约 1 小时 · 读账户与积分（/matrix/api/v1/commerce/get_membership_info）

两份凭证互不通用：拿 JWT 打账户接口一律 401，拿 OAuth 令牌打模型网关同样不通。模型对话用 JWT，积分显示用 OAuth。

现象 · 含义 · 处理方式 正常使用 · 两份凭证都有效 · — 模型报鉴权错误 · JWT 已失效 · 在 MiniMax Code 中重新登录，然后重启 DSH 积分胶囊显示「登录态已过期」 · OAuth 令牌过期 · 插件会用 App 自己的 refresh token 续期并写回；若续期失败，请打开一次 MiniMax Code 桌面 App 让它自行续期

OAuth 令牌过期不会影响模型对话：JWT 仍然有效，模型照常可用，只是积分胶囊暂时拿不到余额。

续期会轮换 refresh token。插件因此把新的一对令牌按客户端原格式原子写回同一个文件，并保持 generation 不变——客户端靠它判断「这份凭据是否仍属于本次登录」，擅自抬高会让桌面 App 误判为异地登录。

关于响应速度

MiniMax 的这些模型强制要求先推理再输出，思考无法关闭。因此：

• 首个字符出现前会有一段等待（实测 M3.1-Flash 约 3 秒）
• 推理过程会以 thinking 块实时返回，可以在界面中看到模型"在想什么"
• 这是模型本身的行为，不是插件造成的延迟

若更看重流式体感的即时反馈，建议同时保留 DSH 官方模型或其他 provider 作为备选。

工作原理

1. 读取 ~/.minimax/local-runtime.auth.json（MiniMax Code 写入的明文登录信息），仅在内存中解析其 JWT
2. 调用 GET /mavis/api/v1/models 获取实时模型目录（含上下文长度、多模态、工具调用等能力声明）
3. 注册 minimaxcode provider，指向 POST /mavis/api/v1/llm/v1/messages（标准 Anthropic Messages 协议）
4. 读取 ~/.minimax/auth/prod//mcode-public/auth.json 的 OAuth 令牌，按需续期
5. 调用 POST /matrix/api/v1/commerce/get_membership_info 获取积分余额，通过插件自己的状态接口 /plugins/dsh-connect-minimaxcode/status 交给界面胶囊

与网关对接时的三个兼容处理

这些是实测中必须处理的差异，也是本插件与"直接改个 URL 就能用"的主要差异所在：

# · 现象 · 处理 1 · 网关只认 Authorization: Bearer，而 pi-ai 默认发 x-api-key，后者单独出现会返回 401 token is required · 在模型描述符上附带 Authorization 头（网关同时接受两个头） 2 · Anthropic SDK 会自己在 baseUrl 后追加 /v1/messages；若 baseUrl 已以 /v1 结尾，请求路径会变成 /v1/v1/messages，网关返回 503 direct_route_not_configured · baseUrl 收到版本段之前，由 SDK 补齐 3 · 所有模型强制要求推理，而"关闭推理"会让 pi-ai 发出 thinking: {type: "disabled"}，网关返回 400 ... requires adaptive thinking · 将"关闭"级别标记为不支持，使该字段被省略（网关接受）

插件不包含任何硬编码的 Token、账号或接口密钥。

自己登录，不装桌面 App

插件可以自己完成登录，用的是 MiniMax Code 桌面端同一套 OAuth 2.0 设备码流（RFC 8628）：

1. 插件向 account.minimax.cn/oauth2/device/code 申请一个设备码，拿到一个 8 位用户码和授权页地址
2. 你在浏览器里打开那个地址，用自己的 MiniMax 账号登录并确认授权
3. 插件轮询 oauth2/token，拿到 mmoat_ 令牌与 refresh token

要点：

• 插件不接触密码、也不接触验证码 —— 唯一的人工环节发生在你自己的浏览器里、账号官方的页面上
• 用了 PKCE：设备码即使泄露，没有本进程里的 verifier 也换不成令牌
• 一枚令牌够用：mmoat_ 令牌既能调模型网关（agent.minimax.cn/mavis/api/v1/llm），也能调账户接口（积分、签到），所以登录一次就够
• 不写客户端的文件：插件把凭据存在自己的 ~/.dsh/.minimaxcode-auth.json（权限 0600，原子写）。桌面 App 的两个文件带 generation 计数器且必须同步递增，写进去会被它当成「在别处登录过」而要求重登
• refresh token 会轮转，插件把新的一对写回自己的文件，所以登录能长期有效

每日签到

MiniMax Code 的免费积分是每天签到送的，不是登录就送。客户端有个「每日签到」卡片，但不会自动领 —— 卡片弹出来，得你自己点。

上游的接口是：

GET  /minimax-cloud/api/v1/signin/status?timezone_id=Asia/Shanghai   # 七天一轮的进度
POST /minimax-cloud/api/v1/signin/claim?timezone_id=Asia/Shanghai   # 领取当天额度

几点实测结论：

• 时区必须是 IANA 名字（Asia/Shanghai）。传偏移量或干脆不传，服务端会回 invalid timezone_id
• 一轮七天：400 / 400 / 400 / 1000 / 400 / 400 / 1000 = 4000 积分
• 签到的积分 30 天有效（响应里的 expire_at_ms 正好是领取日 + 30 天的北京时间零点）
• 按天幂等：当天重复领返回 claim_result: 2（今日已领），不会重复发放

插件页面里能看到当天是第几天、值多少积分、一轮还剩哪些天，并提供两个动作：

• 「签到」按钮 —— 你点一下，插件领当天的额度
• 「每天自动签到」开关（默认关） —— 打开后，插件在检测到「服务端说今天可领」时自动领一次，每天至多一次

自动签到刻意做得很克制：只在上游明确说当天可领时才发请求、当天至多一次、不并发重试、不绕过任何验证，出错就把原因显示出来而不是静默重试。请自行确认这样做符合 MiniMax 的服务条款。

积分余额与用量

输入框工具行（模型选择器旁）的胶囊会显示 MiniMax Code 的剩余积分；点开还能看到赠送/购买拆分、两次读取之间的消耗，以及本机累计的 token 与等效金额。胶囊只在选中 `minimaxcode` 模型时出现。

余额从哪里来

MiniMax Code 桌面 App 自己每天在调一个「会员信息」接口，响应里就带着客户端设置页显示的那三个数字：

POST https://agent.minimax.cn/matrix/api/v1/commerce/get_membership_info
Authorization: Bearer <桌面 App 的 mmoat_ OAuth 令牌>
Content-Type: application/json

{}

"op_credit_summary": {
  "total_remaining_amount": "11459.454",      // 总剩余积分
  "purchased_remaining_amount": "0",           // 其中购买的
  "free_remaining_amount": "11459.454"         // 其中赠送的
}