禁用一个内置 UI 组件

Disable a built-in UI row

别名：关掉一个界面行、摘掉界面行、cordis.patch.yml 停用、disabled true

不装也不卸插件，只在 profile 的 cordis.patch.yml 里按行 id 打一个 disabled: true，就让某个内置界面行不再激活；行还留在树上、删掉那两行即还原，这也正是官方 web bundle 自己往身上摘行时用的手法。

一句话

改的是「行」的激活状态，不是插件装没装。 你在 profile 的补丁层里写两行 YAML，DSH 下次装配时就把那条界面行摘掉；把这两行删掉，它又回来。

贴到哪一层

层	文件	影响范围	优先级
profile 层	`$DSH_HOME/profiles/<name>/cordis.patch.yml`	只有这个 profile	低于 home 层
home 层	`$DSH_HOME/cordis.patch.yml`	这台机器上所有 profile	高于 profile 层

层序与「同 id 的行被后面应用的补丁整段覆盖」的规则见 concept/1；profile 目录本身是什么见 concept/2。两个补丁文件都在热重载监视下，保存即生效，不必重启。

最小片段

# 文件：$DSH_HOME/profiles/<profile>/cordis.patch.yml
# 顶层就是一个 YAML 数组，把下面两项追加进去即可。
- id: ui-jobs        # 目标行的 id（不是包名）
  disabled: true     # 摘掉「会话头部的后台任务列表」；作业的注册表在 host 平面，任务照跑

# 想换成别的行，把 id 换掉即可，例如：
# - id: ui-deliverables
#   disabled: true

就这两行。注意是行 id，不是包名——ui-jobs 这行挂的包是 @deepseek-ai/dsh-client-ui-jobs，补丁里写 id。

为什么是 disabled，而不是卸载或删行

删不掉：这些行是 bundle 层（例如 @deepseek-ai/dsh-web-app）插进来的。你在 profile 层删掉一行，只是删掉了「你自己那份补丁」，bundle 层下次装配照样把它插回来。补丁能做的只有覆盖或停用。
上游自己就这么干：@deepseek-ai/dsh-web-app 的 cordis.patch.yml 里有段注释把理由写死了——把 agent 面挪到预设后面时，它选择禁用而不是删除，因为「base 是共享的，某天有人重排装配，缺失的行会悄悄冒回来」。
loader 真的会跳过它：@deepseek-ai/dsh-app-boot 里处理启动结果的代码对 entry.disabled 是直接 continue（本轮实测的两处）。
比卸载安全：卸载插件会把依赖与其它行一起带走；disabled 只影响这一行，且是可逆的一处文本。

可用的真实行 id（实测来源：`@deepseek-ai/dsh-web-app/cordis.patch.yml`）

行 id	包	摘掉的是什么
`ui-jobs`	`dsh-client-ui-jobs`	会话头部的后台任务列表（任务本身还在跑）
`ui-goal`	`dsh-client-ui-goal`	输入区里的 GoalBar
`ui-deliverables`	`dsh-client-ui-deliverables`	每条回答末尾的「产出文件」行（上游注释：关掉后那块渲染为空）
`ui-message-feedback`	`dsh-client-ui-message-feedback`	助手消息上的点赞/点踩条
`ui-sidebar`	`dsh-client-ui-sidebar`	侧栏
`ui-plan`	`dsh-client-ui-plan`	输入区的计划模式座位（与 `/plan` 通道相关）

改之前先对着本机真实装配看一眼这些 id 在不在树里：

dsh --profile <name> --dump-config | grep -n 'id: ui-'

--dump-config 叠上了你的补丁层，而 --dump-default-config 只有 bundle 层；两者的差异就是「你改的」。

一个来自市场的不同写法（别照抄）

pack/1 丝滑的DSH 的 manifest patch 里，对 ui-settings 那一行用的是配置项而不是停用键：

- id: ui-settings
  name: "@deepseek-ai/dsh-client-ui-settings"
  config:
    enabled: false

这两者不是一回事：disabled: true 是装配期的通用停用；config.enabled 要求目标行自己实现了 enabled 这个配置项，否则写了也只是塞进它的 config。本轮读了 @deepseek-ai/dsh-client-ui-settings 的包内容（lib/index.js 只有一个空的 apply()），没有找到 enabled 配置项，所以这条写法是否真的生效——未核实。要停用，请用 disabled: true。

三个坑

现象	原因
写了没反应，启动只多一行告警	id 没匹配到任何行——补丁只告警、不报错，静默跳过（见 concept/1）
顺手改了 `config`，发现别的键没了	`config` 是整段替换不是深合并：想保留的键要一起写全（实战写法见 tutorial/2）
摘掉一行之后界面报错或功能缺一块	那行可能是「提供服务的那一行」而不是「画界面的那一行」；同域的兄弟行依赖它

未核实 / 未声明

disabled: true 在客户端（浏览器半端）那条链上的完整效果：本轮核实的是装配侧（loader 对 disabled 条目不建 fiber、官方 bundle 自己就用它），没有在浏览器里逐个 id 实测「界面上到底少什么」。
哪些 ui-* 行是「提供服务」而非「画界面」：未核实。上面表格只转述了每行在补丁里的注释，不构成依赖关系判断。特别地，停用 ui-settings 会不会连带影响 ui-settings-general / -models / -plugins 这些兄弟行，本轮没有实测。
config.enabled 这种写法：未核实是否生效（见上一节）。
停用后界面是否给出任何提示：未核实。本轮能确定的是补丁匹配失败时不会有用户可见提示，只有一行告警。

谁引用了这一条

信息表

category: capability.recipe
dshRef: cordis.patch.yml
recipeKind: config
snippet: - id: ui-jobs disabled: true
targetLayer: userspace
titleEn: Disable a built-in UI row
updatedAt: 2026-10-02
why: 补丁层没法「删掉」一个由 bundle 层插进来的行（下次装配又会插回来），disabled: true 是唯一能停用它又随时可逆的写法——行还在树上，删掉这两行就还原。

标签：配方、配置、cordis.patch.yml、UI 增强

按标签浏览：UI 增强（8）