loading the provider directory failed 报错：DeepSeek Harness 提供方目录加载失败修复

loading the provider directory failed: settings are unavailable in this browser 表示 DeepSeek Harness 的设置页在加载提供方目录（llm.providers）时，浏览器上下文拿不到设置镜像，于是页面落到兜底文案。对应动作是「用 dsh web 打印的认证地址重新打开页面，再刷新或重启宿主把页面与宿主的设置通道接回来」——它不是你的模型配置写错了（来源）。

要注意：这句组合报错的完整串来自用户搜索与反馈的场景归纳，官方仓库里能逐字对上的，是它的两个组成部分——「提供方目录加载」和兜底文案 settings are unavailable in this browser。所以下面只写有官方依据的部分：设置数据由宿主提供、页面按一次请求拉取，通道断了就报这句话（来源）。三件事依次讲：它是什么、怎么修、和通用 settings 报错差在哪。

loading the provider directory failed 报错含义：提供方目录为什么加载失败

提供方目录（provider directory）是模型设置页要用的一份「可配置提供方清单」（llm.providers），它和设置镜像拼成同一个快照；当浏览器上下文拿不到设置镜像、这份清单也就跟着加载不出来时，页面对这一步给出的就是「提供方目录加载失败」（来源）。 三部分拼成快照：

按顺序认一遍：

1. 它是「数据没到」，不是「配置写错」：页面只是没拿到快照，磁盘上的配置还在。预期：恢复通道后刷新，模型列表会照常显示。
2. 它发生在浏览器上下文这一侧：宿主进程负责提供设置镜像，页面负责拉取；用错地址、缓存了旧页面、或连接断了，都会落在这一步。预期：换成正确认证地址后能拉到数据。
3. 它常和兜底文案连在一起：镜像没有初始响应时，页面用 settings are unavailable in this browser 兜底，标题里再带「加载提供方目录失败」——本质是同一件事。预期：两个串一起出现是正常现象，不必当成两个错。

记住一句话：它是「页面 ↔ 宿主」的设置通道问题，先修通道，别先改配置。

一个快速判据：模型列表是空的，但配置文件不是。 如果你打开 settings.yaml 看到提供方条目都在、页面却仍显示兜底文案，说明数据根本没从宿主发到页面——这是通道症状，不是文件症状；此时去改 settings.yaml 通常没用，因为页面根本没收到你想纠正的那份快照。

浏览器上下文修法：用认证地址打开与清缓存

修法顺序是「用正确的认证地址打开 → 强刷页面 → 重启宿主重连」——设置镜像由宿主进程提供，把这条请求通道接回来，提供方目录自然能加载（来源）。 按顺序执行：

1. 用 dsh web 打印的认证地址打开：在启动 dsh web 的终端里，复制它打印出来的那个带认证信息的地址，在浏览器里打开。预期：地址里的 ?token= 被兑换成会话，页面能拉到设置与提供方目录。
2. 强刷页面：直接按刷新按钮；还不行就绕缓存重载——macOS Cmd+Shift+R，Windows Ctrl+Shift+R。预期：镜像请求重新发出，兜底文案消失。
3. 换浏览器或无痕窗口再试：换个浏览器、或用无痕窗口打开同一个认证地址。预期：排除掉旧缓存与本地扩展的干扰后，提供方目录正常加载。
4. 重启宿主再重连：在启动 dsh web 的终端按 Ctrl+C，再跑：
   bash

   npx @deepseek-ai/dsh web
   

   预期：终端重新打印监听地址，回浏览器用新地址打开，设置页恢复正常（来源）。
5. 看真实错误：兜底文案会掩盖底层原因。按 F12 打开开发者工具 → Network 面板，刷新页面，看设置相关请求返回了什么（500 / 404 / 超时）。预期：拿到具体失败原因，才能对症下药。

为什么顺序不能反：强刷只是重新发出快照请求、复用同一会话，所以它修的是「页面过期」；用打印的认证地址打开会重建会话，所以它修的是「地址错误或过期」；重启宿主才是重建通道本身，修的是宿主侧故障。从代价最小的动作往下试，命中哪一步就停在哪一步，别为了一个缓存页去重启宿主。

补一句和插件相关的：设置页进不去，插件市场那一栏往往也一起进不去——这时别急着反复清缓存，先确认通道复原；装插件前后的浏览与管理入口是 DSH Plugin Hub，等设置页恢复后再回去操作。

与 settings unavailable 通用报错的区别

两者的关系是「树与枝」：settings are unavailable in this browser 是设置镜像无初始响应的通用兜底，覆盖整块设置通道；loading the provider directory failed 只是其中「提供方目录」这一步的加载失败，通常伴随浏览器上下文问题（来源）。 对照着看：

1. 共同点：都说明「页面没拿到宿主的设置数据」，都别先去改 settings.yaml。预期：先修通道，配置通常无需动。
2. 区别点：本错更聚焦「提供方目录」这一步，凡涉及模型提供方清单的场景优先想到它。预期：能快速把问题收敛到模型设置页。
3. 别再重复造轮子：通用 settings 报错的完整排查（重启宿主、刷新页面、远程 memory scope、看真实错误码）在《DSH 报「settings are unavailable in this browser」怎么办》里已经写全，本篇只补「提供方目录 + 浏览器上下文」这一支。预期：两篇分工不重叠，按现象选一篇即可。

要避免的误判是把它当成 DeepSeek Harness 的 bug。 提供方目录这一步加载失败是「页面 ↔ 宿主」通道断了，不是模型设置代码的缺陷；通道没通时，改模型提供方、重填凭证、重装程序都不管用，还容易引入副作用——先把通道恢复，再回头看设置。

DSH插件 排查注意事项

1. 先修通道再动配置：提供方目录加载失败是读取失败，不是配置损坏。
2. 认准认证地址：只用 dsh web 当次打印的地址打开页面，别用旧标签页地址。
3. 强刷顺序别反：先刷新、再换浏览器、最后重启宿主，省一次启动时间。
4. 远程要重连：SSH/远程浏览器设置不持久，重连后必须刷新页面。
5. 看 Network 找真因：兜底文案下面藏着真实状态码，按它继续排查。

DSH插件 提供方目录加载的官方机制

官方机制两条：设置数据由宿主进程提供、页面按请求拉取；设置作用域有明确状态机，unavailable 时整块设置都会降级。 两点说明：

1. 设置镜像由宿主提供：settings are unavailable in this browser 是 mirrored.error ?? 'settings are unavailable in this browser' 的兜底结果——镜像有错优先显示真实错误，无初始响应才落到这句（来源）。预期：修通道后兜底消失。
2. 远程作用域是 memory 模式：远程浏览器不向宿主持久写入、连接重建后不自动恢复，所以远程访问更易反复出现设置类报错（来源）。预期：远程场景把「重连 + 刷新」当固定动作。

与其在浏览器缓存、认证地址之间来回试，不如把插件管理交给 DSH Plugin Hub：市场、已安装列表和系统日志都在一个界面里，哪一步卡了直接翻日志。

来源：ui-settings-models store.ts（源码）、welcome-store.ts（源码）、Web UI 指南（官方文档）。