v1.4.5：Gemini 4 Argon 回归，诊断信息能看出网络问题

Gemini 4 Argon 重新回到模型列表；诊断信息新增网络部分，能说明请求 PackyCode 时是怎么失败的。

• Gemini 4 Argon 回归：PackyCode 重新提供 gemini-4-argon，插件把它加回模型列表，配置和下架前相同：Gemini 原生协议，1,048,576 上下文，65,536 输出，low / medium / high 三档。还设成 Argon 的会话不用改，直接恢复可用。
• Argon 目前还不太稳：实测中有的请求超过 90 秒仍没有结果，也出现过一次网关返回「无可用渠道」。这是上游的情况，同一时段 Flash 也会卡住。遇到时重发或先换一个模型。
• 诊断信息新增 network 部分：有 Ubuntu 用户的请求反复重试，日志一会儿写 Request timed out.，一会儿写 Connection error.，其实是同一个问题：IPv6 地址连不上，IPv4 握手又超过了 Node 给每个地址的 250 毫秒，而原来的诊断信息看不出这些。现在 设置 → PackyCode → 诊断信息 会记录插件连接 PackyCode 服务器的请求数、状态码、失败阶段和耗时，以及每次失败试过的地址和错误码。不读取请求头、正文、查询参数和代理地址。这部分统计整个进程，不限于所选会话。这个版本只让问题看得出来，没有改变连接方式。

验证：548 项测试、两份构建和发布包检查通过。通过插件实测：Argon 正常回答，认对了红、蓝两张图片；原生工具调用 10 轮里 6 轮续接回 ok（low 4 轮，medium、high 各 1 轮），没有出现签名拒绝，另有 3 轮超过脚本的 90 秒上限，1 轮被网关以「无可用渠道」拒绝。直连采样 16 次，Argon 成功 15 次，Flash 成功 12 次，其余都超过 90 秒。全模型实测中只有 grok-4.7 没有回答：PackyCode 现在只把它列在 grok-sale 分组，测试 Key 没有这个分组，插件这边没有改动。网络部分在 DSH 桌面应用自带的 Node 和 undici 下验证了模拟的连接失败和真实请求的统计。新版本尚未在 DSH 桌面端和 Linux 上验证。

在 DSH 插件管理中更新至 1.4.5，然后重新打开 DSH 加载新版。

v1.4.4：新增 DeepSeek V4 Pro，移除已停服的 Gemini 4 Argon

模型列表新增 DeepSeek V4 Pro，同时移除 PackyCode 已停止提供的 Gemini 4 Argon。

• DeepSeek V4 Pro：deepseek-v4-pro 与 DeepSeek Flash 一样走 Responses 协议，1M 上下文，最多输出 384K；推理可关，另有 low / high / max 三档。需要 Key 的分组包含 deepseek-officially 或 deepseek-sale。在模型选择器里排在 Flash 之后，设置页「显示的模型」里也能勾选。
• V4 Pro 只收文字：按 DeepSeek 官方文档，只有 Flash 能看图。PackyCode 网关收到发给 V4 Pro 的图片不会报错，而是直接丢掉，模型只能对着一张没收到的图猜。所以插件声明它只收文字：DSH 不让给它附图；会话里已有的图片（比如从 Flash 切过来的会话）会换成一行「图片已省略」的说明再发送。要看图请用 Flash。
• V4 Pro 的会话标题交给 Flash：Flash 便宜得多，能用 V4 Pro 的分组都能用 Flash。
• Gemini 4 Argon 下线：PackyCode 自 2026-10-27 起不再提供 gemini-4-argon，网关拒绝这个模型，公开模型列表里也没有了，插件已从目录中移除。还设成 Argon 的会话会报 pi-ai provider "packycode" has no configured model "gemini-4-argon"，在模型选择器里换一个模型即可。Gemini 3.8 Flash 不受影响。

验证：536 项测试、两份构建和发布包检查通过。直连网关实测 V4 Pro：关闭推理及 low、high、max 都按原样生效，输出上限与 Flash 相同；工具没写 strict 时，它和 Flash 一样不会乱填可选参数。通过插件实测：四个档位都正常回答；带工具调用时在 high、关闭推理和 max 下都能续接回 ok；会话标题由 Flash 生成；带图片的会话没有把图片发出去，模型直接说明看不到图片。全模型实测中十一个模型都正常回答。新版本尚未在 DSH 桌面端验证。

在 DSH 插件管理中更新至 1.4.4，然后重新打开 DSH 加载新版。

v1.4.3：修复 GPT 改文件时报 invalid justification

修复 GPT 模型（GPT-6.1 Terra 上最明显）改文件或执行命令时报 Error: invalid justification: expected a non-empty sentence 的问题。

• 原因：插件把 DSH 的工具发给 GPT 时没有写 strict，PackyCode 的 GPT 通道就按严格模式处理，模型被迫填满所有可选参数。DSH 的沙箱提权参数于是被填成 sandbox_permissions: "workspace-write" 加空的 justification，DSH 的 edit / write 拒绝了这次调用；会话不在 workspace-write 模式时，bash 也会拒绝。模型还会顺手编出 timeoutMs: 1000 之类的参数。四个 GPT 模型都有这个问题，1.4.2 之前就存在。
• 修复：GPT 的工具定义现在显式带上 strict: false（官方 Codex 客户端也这样发），参数说明保持 DSH 原样。模型不再自己填沙箱参数；沙箱真的拦下命令时，它仍会带着理由申请提权，由你确认。
• 其他模型：DeepSeek Flash 和 Grok 4.7 本来就不会填这些参数，不受影响；Claude 和 Gemini 走各自的协议，也没有变化。
• 已经出错的会话：被拒的只是那一次工具调用，模型通常会换一种方式完成，不需要处理。

验证：537 项测试、两份构建和发布包检查通过，新测试在修复前会失败。用 DSH 0.2.1-rc.3 自带的工具定义实测：修复前 Terra 15 次调用全都带着空的 justification，其中一次 edit 被 DSH 以同样的报错拒绝；修复后 Terra 和 GPT-6.1 Sol 各 9 次调用都没有再填这两个参数，也没有被拒，沙箱拒绝命令后两者仍各 3 次带理由申请提权。全模型实测中十个模型正常回答；Gemini 4 Argon 当天已不在 PackyCode 的公开模型列表中，网关拒绝这个模型，与本次修复无关。新版本尚未在 DSH 桌面端验证。

在 DSH 插件管理中更新至 1.4.3，然后重新打开 DSH 加载新版。

v1.4.2：新增 GPT-6.1 Terra

新增 OpenAI 的 GPT-6.1 Terra（gpt-6.1-terra）：价格是 GPT-6.1 Sol 的一半，也是唯一可以关闭推理的 GPT 模型。

• 新模型：GPT-6.1 Terra 和 GPT-6.1 Sol 走同一条 Responses 通道，支持文字和图片输入，上下文 1,050,000 token，单次最多输出 128,000 token，数据来自 OpenAI 官方模型页。模型选择器里它排在 GPT-6.1 Sol 后面。Key 需要在 codex 或 codex-sale 分组，设置页「账户与 Key」的 GPT 一栏会显示每个 Key 能否使用。
• 可以关闭推理：档位有关闭和 low / medium / high / xhigh / max。关闭时发送 OpenAI 文档列出的 none，经 PackyCode 实测原样生效，不产生推理 token。GPT-5.6 Sol 的文档也列出 none，但经 PackyCode 会按 medium 回答，GPT-6.1 Sol 则直接拒绝，所以这两个模型仍不能关。
• 会话标题：Terra 比 GPT-6.1 Sol 便宜，所以 Terra 会话的标题由它自己生成；GPT-6 Astra 和 GPT-5.6 Sol 的标题仍交给 GPT-6.1 Sol。

验证：536 项测试、两份构建和发布包检查通过。用 codex 分组的 Key 实测：直连网关时六个档位都按原值生效，关闭推理时推理 token 为 0；经插件路由，各档位、识图（红、蓝两张图）和工具调用续接（high 与关闭推理各一次）全部通过；全模型实测中 11 个模型都正常回答，Key 轮换、失效 Key 识别、自动审查和设置页收到的数据都没有变化。新版本尚未在 DSH 桌面端验证。

在 DSH 插件管理中更新至 1.4.2，然后重新打开 DSH 加载新版。

v1.4.1：cc 分组的会话标题恢复正常

修复 1.4.0 中 cc 分组 Key 的 Claude 会话标题变成 “Untitled Session”“Empty Session” 的问题：生成标题时，Claude Code 现在能看到要命名的对话了。

• 标题按对话内容生成：DSH 生成标题时，把你发过的消息放进一条单独的消息交给模型，这条消息标的是 DSH 自己的来源，不是“用户”。1.4.0 起 cc 分组只把你本人发的消息交给 Claude Code，这条消息就被滤掉了，模型只能给一段空对话起名，标题于是成了 “Untitled Session”“Empty Session”“空白会话” 之类。现在标题请求原样交给 Claude Code；这条消息里只有你发过的话，不含 DSH 给自己的 agent 附加的内容。
• 长消息不再被截断：以前每条消息只取前 2000 个字符，开了 DSH 实验性插件「随对话更新的标题」时，最新的几条消息会被截掉。现在和 HTTP 通道一样整段交给模型，长度由 DSH 自己限制（默认 4096 字节）。
• 测试改用 DSH 真实的标题请求：测试和实测脚本以前把要命名的内容当成用户本人的消息发送，所以没发现这个问题；现在用的是从 DSH 0.2.1 标题插件原样拷来的请求。
• 已有的标题：DSH 默认只在会话的第一条消息后生成一次标题，已经生成的错误标题不会自动更新，可以手动改名；开了「随对话更新的标题」的会话，发下一条消息时会重新生成。其他分组和其他模型不受影响。

验证：535 项测试、两份构建和发布包检查通过；新的标题测试在 1.4.0 的代码上会失败。用同一个 cc Key 和 Claude Code 2.1.295 实测 DSH 真实的标题请求：修复前，Opus、Sonnet、Haiku 三次全部失败，标题是 “Greeting”“空白会话”“空白会话”；修复后连跑三轮，9 次全部通过，标题如“仓库发货安排核对”“仓库发货安排与缺货采购”，没有请求被判客户端异常。新版本尚未在 DSH 桌面端验证。

在 DSH 插件管理中更新至 1.4.1，然后重新打开 DSH 加载新版。

v1.4.0：cc 分组的 Claude 会话改由 Claude Code 自己完成

cc 分组 Key 的 Claude 会话改由本机的 Claude Code 当 agent，修复“客户端存在异常”的拒绝；DSH 负责工具卡片、授权、计划审阅和提问。

• 修复“客户端存在异常”：PackyCode 的 cc 分组按请求内容判断是不是 Claude Code 自己在工作。1.3.4–1.3.9 借官方 CLI 发出的是 DSH 的系统提示词和工具，带工具的请求大约一半被判为客户端异常，换编码类任务时第一个请求就被拒；更新 CLI 也没用。现在 Claude Code 用它自己的系统提示词和工具做事，和 paseo 等工具使用官方 CLI 的方式一样；DSH 为自己的 agent 附加的内容（AGENTS.md、运行环境、时间、技能列表和各类提示）也不再交给它，它只收到你发的消息。在三个 Claude 模型上实测，这样的请求没有再被拒。
• 工具调用显示成卡片，授权由 DSH 决定：Claude Code 的每次工具调用都显示成 DSH 的工具卡片（命令是终端卡片，改文件是 diff）。它请求授权时，按会话的权限预设处理：workspace-write（默认）下工作目录内改文件直接进行，非只读命令等操作会弹出 DSH 的授权提示；read-only 下改文件也要授权；auto 下交给自动审查，审查拒绝时再问你；danger-full-access 下不询问。你拒绝时，理由会原样告诉 Claude Code。
• 计划模式和提问在 DSH 里完成：/plan 后 Claude Code 进入它自己的计划模式，写好计划后交给 DSH 的计划审阅；批准后按预设继续，选「继续规划」时你的反馈会交给它修改。它向你提问时，问题出现在 DSH 的提问界面。
• 会话可以续接：一个 DSH 会话对应一个 Claude Code 会话。进程空闲结束、DSH 重启、换模型或换 Key 后，都能接着原来的会话；编辑过历史消息或从别的模型切过来时，从 DSH 的历史新开一个。你在它工作时插话，插件会停下它当前的请求，把这句话作为下一条消息交给它。
• 分组读不到时先走 CLI：插件还没读到 Key 的分组（刚启动、网络或代理不稳）时，Claude 请求先交给 Claude Code CLI：cc 分组的 Key 走 HTTP 一定被拒，而官方客户端各个 Claude 分组都接受；读到分组后，其它分组再改走 HTTP。一轮对话从 CLI 开始，就在 CLI 上做完。读取失败的 Key 约 30 秒后重读，不再等 10 分钟。
• 修复单分组 Key 读不出分组（#3）：网关对只有一个分组的 Key 改用「分组 cc-sale 下模型 … 无可用渠道」的拒绝文案，插件现在也能从中读出分组。
• 需要注意的差别：命令和文件修改由 Claude Code 在本机直接执行，不经过 DSH 的沙箱，只受上面的授权把关。DSH 自己的工具（子代理、todo、后台任务、生图、DSH 搜索等）在这些会话里不可用，Claude Code 用它自己的同类工具。项目里的 CLAUDE.md 会生效。cc-sale、cc-expensive、claude-officially 等其他分组不受影响。
• 报错说明更正：cc 分组仍判定为客户端异常时，提示不再建议更新 CLI，而是说明这是按请求内容的判定，可以重发一次，反复出现时把原文发给 PackyCode 客服或改用其他分组的 Key。

验证：535 项测试、两份构建和发布包检查通过。用同一个 cc Key 实测：改动前，旧通道的 15 项检查失败 7 项；改动后，claude-check --transport cli 在 Opus、Sonnet、Haiku 上各跑 7 个场景，21 项全部通过。这 7 个场景是读文件计算、需授权的修改、被拒绝的删除、计划审阅后实施、提问、看图和起标题，共 53 个请求，没有一个被判客户端异常或反滥用。在无头 DSH 0.2.1-rc.3 里用真实 CLI 跑了 10 个任务：授权批准和拒绝、计划审阅（先要求修改一次再批准）、提问、换进程续接、自动审查放行和转问用户，都按预期完成。在 DSH 桌面端检查了读文件卡片、授权提示的批准和拒绝、/plan 计划审阅后实施、提问界面和重启后续接，都正常；这次检查发现并修掉了几个问题：分组读得慢时第一个请求走了 HTTP、桌面端 /plan 没有切到 Claude Code 的计划模式、DSH 的上下文消息被转给了 Claude Code、先用别的模型建的会话每轮第一步缺少镜像工具。CLI 2.1.259 与 2.1.295 都支持插件用到的授权和模式切换。live-check 中其他模型、Key 轮换、两种自动审查模型和设置页接口都正常；grok-4.7 被网关以分组不覆盖该模型拒绝，测试 Key 的 grok-officially 分组目前不提供它。

在 DSH 插件管理中更新至 1.4.0，然后重新打开 DSH 加载新版。

v1.3.9：更新失败时说明原因

点「更新插件」失败时，如果是安装源还没同步新版本或者连不上，设置页会直接说明，不再只显示「更新失败」。

• 安装源还没同步：插件从 npm 读到新版本号，DSH 的 pnpm 却从 profile 配置的安装源下载。刚发布的版本，安装源可能还没同步：1.3.8 发布 36 分钟后，npmmirror 仍然只有 1.3.7；npm 自己的 CDN 也可能在几分钟内对新包返回 404。以前这时只显示「更新失败，请重试，或在插件页重新安装。」，现在会写明是哪个安装源还没同步，请你过几分钟再更新。
• 连不上安装源：pnpm 连不上安装源（域名解析失败、连接被拒、连接重置或超时），或者安装超过 3 分钟还没结束，会提示检查网络或代理后重试。
• 其他情况不变：其他原因的失败仍显示原来的提示，插件也不会自动切换安装源。页面上只显示安装源的域名，地址里的路径、凭据和 pnpm 的输出都留在 Host 端。
• 超时不再被当成普通失败：以前 pnpm 卡住、被插件按时结束后，Node 先报出自己的中止错误，「超时」这个原因就丢了，结果只显示笼统的失败。现在会正确提示连不上安装源。

验证：515 项测试、两份构建和发布包检查通过。用 DSH 自带的 pnpm 11.28.5 在装有 1.3.7 的临时 profile 中实测：官方源正常更新到 1.3.8；npmmirror（当时还没有 1.3.8）0.9 秒内提示还在同步；连接被拒的源在 pnpm 自己重试完后（约 70 秒）提示连不上；不回包的源到时间上限时提示连不上（测试时上限设为 20 秒），profile 没有改动，也没有残留的 pnpm 进程。提示文字通过界面测试检查，新版本尚未在 DSH 桌面端界面中验证。

在 DSH 插件管理中更新至 1.3.9，然后重新打开 DSH 加载新版。

v1.3.8：自动审查可改用 jev-latest 或 DeepSeek Flash

开启 DSH 自带的「自动授权审查」后，权限菜单里的「自动审查」可以改用 PackyCode 的 jev-latest 或 DeepSeek Flash 审查每次工具调用，审查规则和处理方式保持官方原样。

• 自动审查可换审查模型：DSH 自带的实验插件「自动授权审查」默认关闭，在左侧「插件」页开启后，权限菜单里会多出「自动审查」。每次工具调用前先由模型审查：放行的直接执行，拒绝的改为请你批准。它默认用当前对话的模型；现在可以在「设置 → PackyCode → 自动审查」改成 jev-latest（默认）、DeepSeek Flash，或保持跟随对话模型。审查看什么、按什么规则、放行和拒绝后怎么处理，仍由官方插件决定，本插件只替换回答审查的模型。
• 接入 jev-latest：TypeSafe 的决策分类模型，走 PackyCode 的 /v1/systemone（typesafe-officially 分组）。它不能对话，所以不在模型选择器里。插件把官方的审查内容和规则原文交给它，再把结果换算成官方要求的放行或拒绝答复；一次约 0.4 秒，只按输入计费。「账户与 Key」里每个 Key 会显示能否调用 Jev。
• DeepSeek Flash 审查：官方的审查请求原样改发到 PackyCode 的 DeepSeek Flash，一次约 2 秒，拒绝时写明原因。
• 设置卡片：显示官方插件是否已开启及开启方法、所选审查模型、本插件处理过的审查次数（放行 / 拒绝 / 失败）和最近一次结果；没有 Key 能调用所选模型时会提示。权限菜单里「自动审查」的说明文字仍是 DSH 的「由同一模型审查」，实际以设置为准。

验证：510 项测试、两份构建和发布包检查通过。用官方的审查请求格式和官方解析器在 37 个场景上实测，两个审查模型在 35 个有明确答案的场景上全部符合预期（jev-latest 中位 0.35 秒，DeepSeek Flash 中位 2.3 秒）。在开启官方插件的临时 DSH 0.2.1-rc.2 中实际发起强推：三种设置分别由 jev-latest、DeepSeek Flash 和对话模型审查，官方插件据此发起审批。十个模型、Key 轮换、失败分类和新增的审查检查实测正常。新版本尚未在 DSH 桌面端界面中验证。

在 DSH 插件管理中更新至 1.3.8，然后重新打开 DSH 加载新版。

v1.3.7：GPT 网页搜索恢复可用

GPT 搜索后端改为流式读取，修复每次搜索都报 "returned no web_search_call" 的问题；Claude Code CLI 卡片在有新版本时也会提示更新。

• GPT 网页搜索恢复可用：PackyCode 的 Codex 通道对非流式 /v1/responses 请求返回 completed，搜索其实已经执行，但 output 为空，1.3.6 因此每次报 "PackyCode search returned no web_search_call"。现在 GPT 搜索改为流式，从 response.output_item.done 事件重建结果，来源和摘要的取法与以前相同。
• 上游临时满载时自动重发：网关在流中转发的 "Temporary capacity limit"（rate_limit_exceeded）和 server_error，会按提示的间隔在同一个 Key 上最多重发两次，不会因此停用 Key；仍失败时，错误会注明模型并建议改用 DeepSeek 后端。流中的其它错误直接报出上游原话。
• 始终发送 prompt_cache_key：Codex 分组会以 403（「请使用标准 Codex 客户端」）拒绝不带这个字段的请求。DSH 内的搜索本来就带会话 id，没有会话的调用方现在也会自带一个。
• Claude Code CLI 有新版本时提示更新：以前只有低于 2.1.259 的 CLI 才显示「更新 Claude Code CLI」。现在插件在本机读取 npm 上 @anthropic-ai/claude-code 的 latest（30 分钟内最多读一次，点「重新检测」立即重读，读不到时不提示），能用但不是最新版的 CLI 会显示新版本号和同一个按钮。
• 更新结果判断更准：已经能用的 CLI 更新后版本没变、而又有更新的版本时，会显示安装器自己的输出（例如 Homebrew 的 brew upgrade claude-code），不再误报「已更新」。

验证：480 项测试、两份构建和发布包检查通过。实测 Codex 分组：非流式搜索 3 次都返回空 output，流式时结果全部在 output_item.done 事件里；28 次 GPT 搜索经新逻辑解析，每次得到 13–20 个来源和摘要，多数在 10–30 秒内完成（DSH 桌面版给网页搜索 60 秒）。十个模型、Key 轮换与失败分类实测正常，DeepSeek 搜索 6 秒返回；当时 GPT 搜索碰上上游满载，三次都未成功，按新格式报错。CLI 更新提示在临时目录中把 npm 安装的 2.1.295 更新到了 2.1.303。未在 DSH 桌面端实机对话验证。

在 DSH 插件管理中更新至 1.3.7，然后重新打开 DSH 加载新版。

v1.3.6：DeepSeek Flash 改走 Responses

DeepSeek Flash 改用 PackyCode 网关的 Responses 接口调用，推理档位、识图和工具调用照常可用。

• DeepSeek Flash 走 Responses：deepseek-flash 的请求从 /v1/chat/completions 改发到 /v1/responses，base URL 仍是 https://cf.api.fan/v1，需要的分组不变（deepseek-officially、deepseek-sale）。PackyCode 的模型目录已列出它支持 Responses。
• 推理档位不变：仍可关闭，或选 low / high / max。关闭时发送 reasoning.effort: "none"，网关返回时不带思考；开启时思考内容实时显示，并随同一轮的工具调用一起回传给模型。
• 缓存与图片：和 Grok 一样不发送 prompt_cache_key，前缀缓存照常命中；图片以 input_image 随请求发送。
• 旧会话可继续：以前经 Chat Completions 聊过的 DeepSeek 会话可以直接接着聊，之前的思考内容会作为普通文字带上。
• 其它：目录里已没有模型使用 Chat Completions，插件不再加载这套接口；读取 Key 分组的探测请求不受影响。

验证：461 项测试、两份构建和发布包检查通过。直接请求网关时，deepseek-flash 在 Responses 上各推理档位都返回 200，none 时不产生思考；输出上限 384,000 在网关允许的 393,216 以内。经插件实测四轮工具对话：high、max、关闭、混合档位以及多段思考回传都正常，不带 prompt_cache_key 也命中缓存，Chat Completions 开始的会话能在 Responses 上继续。十个模型、Key 轮换与设置页接口的实测均正常，DeepSeek 识图正确认出红、蓝两张图。未在 DSH 桌面端实机对话验证。

在 DSH 插件管理中更新至 1.3.6，然后重新打开 DSH 加载新版。