[bug] Desktop 和CLI auth login 设置的供应商配置被opencode.json中的配置静默覆盖，对应供应商被划入disabled_providers，Disconnect 后无 UI 入口恢复

Description

描述

opencode auth login（CLI）和 Desktop Settings 面板都会让用户填一把 key，存到 ~/.local/share/opencode/auth.json——但既没在文档里、也没在 UI 里告知用户：只要 opencode.json 里 provider.<id>.options.apiKey 存在（哪怕只是 {env:VAR} 模板），它就无条件覆盖 auth.json 里那把 key。配置后调用失败报Authorization Required后、用户点 Disconnect 想重配——provider 又被永久写进 disabled_providers，TUI/Desktop 的 /connect picker 都再看不见它，UI 没有任何反向入口。

两条独立看都还能辩护的行为，串成了一个用户无法自行恢复的状态：

• 静默覆盖：用户填的 key 没生效，但错误信息（"Authorization Required"）不告诉他是哪把 key 在被用，他无法判断是配错了还是被覆盖了。
• 永久禁用 + 无 UI 恢复：调用失败后再Disconnect 不是"删凭据"，而是"把供应商从列表里永久抹掉"。Desktop 用户尤其卡死——通常没有"打开 opencode.json 手动编辑 disabled_providers 数组"这条心智通路。

影响范围

入口	写入位置	被 options.apiKey 静默覆盖	Disconnect 后能否 UI 自救
opencode auth login（CLI）	auth.json	是	否（但 CLI 用户还能编辑 JSON）
Desktop Settings 面板	auth.json	是	否，且UI无任何配置文件编辑入口
TUI /connect	auth.json	是	否

三种入口写入的是同一个 auth.json，受同一条规则约束。CLI/TUI 用户中招后起码能从命令行自救；Desktop 用户在 Settings 里删了一个供应商后，再也找不回加它的入口——除非他事先知道要去找一个他从未被引导去看的 JSON 文件。

Desktop 用户的真实旅程

步骤	用户做了什么	OpenCode 实际做了什么	UI 反馈
1	在 Settings 里搜到 DeepSeek，填入有效 key	写到 auth.json	提示已连接
2	发起一次对话	用了环境变量里那把旧 key（options.apiKey 优先）	"Authorization Required"
3	失败信息没说哪把 key 被用，用户以为是刚配的那把坏了	—	没有诊断提示
4	点 "Disconnect" 想清掉重配	把 "deepseek" append 进 opencode.json 的 disabled_providers[]	提示 "Disconnected"（没说"永久隐藏"）
5	重启 Desktop，再次打开 Settings 想重新加	provider 已从 picker 抹掉	找不到
6	Settings 没有"显示已隐藏的供应商"开关	—	—
7	唯一出路：手动编辑 opencode.json 删字符串	Desktop 用户基本不会去碰这个文件	—

整个过程里没有一步是用户操作失误——每一步都按 UI 的提示做了。问题在于 UI 暗示的行为和系统实际的行为系统性地不一致。CLI/TUI 用户在步骤 5 后还能 opencode auth list 看到_entries、能从命令行编辑配置；Desktop 用户卡死在第 5 步。

根因（代码定位）

1. 优先级未文档化——auth.json 被 opencode.json 静默覆盖

packages/opencode/src/provider/provider.ts 的 resolveSDK 函数（~L1668）：

if (options["apiKey"] === undefined && provider.key) options["apiKey"] = provider.key

实际生效的优先级：

1. opencode.json 里的 provider.<id>.options.apiKey（含 {env:VAR} 模板解析结果）—— 一旦存在就赢
2. auth.json（opencode auth login / /connect / Desktop Settings 写入）
3. 环境变量（仅当 provider.env.length === 1 时才被读取）

docs/providers 推荐 "apiKey": "{env:DEEPSEEK_API_KEY}" 写法，未警示这会让 auth.json 里存的 key 完全失效。docs/cli/ 的 opencode auth login 段只说"先加载 credentials file，再读环境变量"，未提优先级最高的 options.apiKey。用户读不到、也不会去读这个细节——他们看到的就是"我填了 key，但它没生效"。

2. 调用失败后Disconnect = 将供应商剔除列表，无 UI 反向

packages/app/.../settings-providers.tsx 的 disableProvider 函数（L94-L112）：把 provider ID 直接 append 进 opencode.json 的 disabled_providers[]，TUI 和 Desktop 的 /connect picker 都会过滤掉。

• 没有确认 dialog 告知"会从列表中永久移除"
• toast 文案是 "Disconnected"，不是 "已从供应商列表永久隐藏"
• 没有 UI 入口 能反向把 provider 从 disabled_providers 移除
• Settings 面板没有"显示已隐藏的供应商"开关

对 Desktop 用户而言，等同于"我在 Settings 里删了一个联系人，发现没法重新添加，因为他根本不在搜索结果里了"——而这件事完全没在 UI 中提示。

期望行为

• options.apiKey > auth.json > 环境变量的优先级写进文档（docs/cli/ 和 docs/providers/）
• Desktop Settings / TUI /connect 在 opencode.json 已设置 options.apiKey 时，应给出可见提示"已存在配置文件项，此处填入的 key 不会生效"
• 调用失败时不应直接将 provider ID 直接 append 进 opencode.json 的 disabled_providers[]，应给予用户充分的界面提示和恢复能力
• Desktop Settings 提供"显示已隐藏的供应商"开关或 disabled_providers 编辑入口
• 或将"删除凭据"和"禁用供应商"拆成两个语义独立的动作
• 在Desktop Settings提供修改opencode.json的功能，且妥善处理两处配置的优先级

相关 issue

• #31242（open，已分派 @kitlangton）—— v1.16.2 CLI 下 DeepSeek /connect 找不到，根因可能相同
• #29128（closed as not planned）—— Desktop 下相同症状，被关时根因未被识别
• #31832、#12407 —— disabled_providers 在 CLI/TUI 之间执行不一致

Plugins

oh-my-opencode 4.19.0

OpenCode version

• OpenCode 版本：v1.18.x（dev 分支，2026-07-27）

Steps to reproduce

复现步骤

1. 在系统环境变量里设置一个故意失效的 DEEPSEEK_API_KEY=sk-invalid
2. 通过 opencode auth login 或 Desktop Settings 给 DeepSeek 配上有效 key（写入 auth.json）
3. 确保 opencode.json 里有 provider.deepseek.options.apiKey = "{env:DEEPSEEK_API_KEY}"
4. 调用 DeepSeek → 失败，报 "Authorization Required"
5. 在 Desktop Settings 或 TUI 里点 "Disconnect"
6. 重启，打开 Settings 想重新加 → DeepSeek 不在供应商列表里
7. 重启、清缓存、重装——都救不回来，唯一恢复方式是手动编辑 opencode.json

实际行为

• opencode auth login 和 Desktop Settings 写入的 key 被 opencode.json 的 options.apiKey 静默覆盖，无任何提示
• Disconnect 后供应商永久从列表消失，UI 提供不了反向操作
• Desktop 用户必须手动编辑 JSON 文件才能恢复——UI上无任何入口

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

Windows Terminal