dshseek

seek://news/dsh-tui-v0-18-0

dsh-TUI 0.18.0:验证线升至 rc.5(11 月 1 日)

2026年11月1日release#release #dsh-tui #clients← 全部资讯

TL;DR

据 npm registry,dsh-TUI 0.18.0 于 2026-11-01 03:43 UTC 上架,距 0.17.0 八天。按发布说明,PR #1806 把验证线挪到 DSH 0.2.1-rc.5——此前宿主升级过 rc.3 后,插件兼容检查会拒绝加载 TUI;同时首启引导可直接登录或加 key,/plugin list 接入官方 create_worktree 开关。

dsh-TUI 0.18.0 把验证线挪到 rc.5,终结升级 DSH 后拒绝加载的问题——距 0.17.0 八天,首步登录与官方 Git 工作树开关同车。

v0.2.1-rc.5:思考内容显示修复(10 月 30 日)的报道止于 harness 本体;这里是同一串版本号的生态侧。dsh-TUI——全屏终端客户端——于 11 月 1 日 03:43:39 UTC 把 0.18.0 发上 npm,距 0.17.0 八天,正对准宿主 rc.4 与 rc.5 为它竖起的兼容墙。

拒绝加载,与修它的那条线

据发布说明,机制出在宿主的插件兼容检查上:v0.17.0 只声明支持到 DSH 0.2.1-rc.3,npm 上的 DSH 移到 rc.4 与 rc.5 后,升级宿主便让 TUI 拒绝加载。PR #1806(2026-10-30 合入,作者与下面的引导 PR 同为 @AdamPlatin123)把 rc.4 与 rc.5 挪进验证线与 peer 范围,dst 自动化适配器的验证版本同步跟进。发布说明还为「这次挪线风险不大」自带论据:按发布包逐文件比对,TUI 用到的上游代码在 rc.3 到 rc.5 之间只改了版本号,宿主复刻指纹不变。该比对是发布方的声明,按原样引用——本文核实的是时间戳与合入,不是逐字节比对。

首步登录,以及它带回来的东西

第二个头条是首启引导。据发布说明,引导第一步现在能登录订阅账号或添加模型提供方——后者沿用 /provider 向导——在终端本身开始工作之前完成,也可以重新检查或跳过这一步。订阅登录会带回模型,发布把采用方式写成 0/1/N:只报结果、直接设为默认、或在内联选择器里挑一个;按发布说明,/provider 向导的切换题会逐项列出本次登录启用的模型,并保留「保持当前模型」。

官方工作树开关,与跟着插件走的授权

据发布说明,还有两个更安静的变化补齐功能面。/plugin list 现在可以直接开启 DSH 官方的 create_worktree 实验工具(PR #1745,10 月 24 日合入):工具卡标题显示分支名,结果用两行写明检出位置和起点。Minimal 预设与随包的 liangshen 预设不提供该工具——Minimal 的持久 shell 不跟随目录——工作树也不会自动清理,分支需要另外删除。插件授权则跟随生命周期(PR #1747,10 月 26 日合入):安装或启用时按包自己的声明授予,关闭时撤销,卸载时删除,后来复用同一组件 id 的包不会静默继承先前的授权。/plugin enable 确认页逐行列出声明的权限并按终端高度折叠;按 Esc 即放弃。一并到来的还有一处行为变化:@~/… 在任意深度都指向家目录,与 shell 一致;工作区里真有名为 ~ 的目录时改写成 @./~/…(PR #1739)。

往后的契约

据发布说明,0.2.1-rc.5 是主适配线;rc.4、rc.3、rc.2、0.2.0-rc.1、0.2.0-rc.2 及更早仍在契约内,契约之外打漂移警告。发布直接回应了已被锁在门外的用户:程序内 /update 需要能打开 TUI,所以说明让他们直接走 npm 升级命令,并声明先前为 v0.17.0 用 dsh plugin allow-version 加过的豁免在升级后不再需要。Windows 离线安装器随契约验证到 rc.5,会把 rc.4 宿主升上去而不是降回 rc.3——发布说明说 v0.17.0 的安装器正是降回 rc.3 的。

同系列其它条目

官方参考