新增功能：粘贴 Token 添加账号
设置 → 插件 → DSH CodeBuddy CLI Connect → 账号管理 →「粘贴 Token 添加」。填入 refresh_token 即可加入一个 CodeBuddy 身份，无需扫码登录。
为什么必填 refresh_token、而 access_token 可选（实测上游行为）：
access_token寿命固定（实测expiresIn= 55 天），且无法反向续期；refresh_token可独立恢复会话——刷新接口既不需要access_token，也不需要X-User-Id；- 因此只填
refresh_token即可完整添加一个账号；填access_token能省一次刷新。
uid 与昵称由 Token 中的 JWT 自动解析；「登录区域」可选国内（www.codebuddy.cn）／国际（www.workbuddy.ai），因为仅凭 refresh_token 导入时没有 JWT 可读取区域，而会话基址依赖该值。
验证顺序：先探活，再落库
- 本地解析 JWT 取
uid/ 昵称 / 有效期； - 用
refresh_token换取新令牌（证明账号可用）； - 用新的
access_token拉取模型目录； - 全部通过后才写入账号存储。
任一步失败不写入任何内容——一个存在但无法鉴权的账号比没有账号更糟，因为切换器会把它列出来。失败原因就地显示，已粘贴内容保留便于修改。
两个由上游行为决定的正确性细节
- 落库的是上游轮换后的新令牌对，而非粘贴的旧值：实测刷新会轮换
refresh_token且旧值在服务端仍有效，存回旧值会留下一个本插件无法跟踪的长期有效凭证。 - 导入时顺带读取积分：此前新账号卡片的余额是空的，要等下一轮轮询才补上，看起来就像导入失败。现在积分在探活时一并读取并写入按账号的积分缓存，新卡片立刻显示余额与积分包。积分读取失败不影响导入本身（账号已确认可用，余额稍后补齐）。
兼容 DSH 0.1.7+ 新版设置 API（托管表单）
DSH 的 dsh-settings 设置接口经历过三代演进，旧写法在新宿主上会失效：
installSettingsSection(...)——@deepseek-ai/dsh-settings导出的模块级函数；settings.installSection(...)—— 同一个辅助函数被移到 settings provider 服务上（DSH 0.1.2+）；- 托管表单（DSH 0.1.7+）—— 上述两个安装器都被移除，表单改由插件自身 Loader 入口的 Config schema 推导，插件只能通过
configure({ auto: false })选择不自动生成页面。
本次新增 src/settings-compat.ts 在运行时自动识别当前宿主属于哪一代，因此同一份构建产物在整个 peer 范围内（0.1.2-rc.1 ～ 0.1.7+）都能正常工作；在旧宿主上各分支都会降级回原有行为，不会抛错。同时补了 settings-compat 与 client-bundle-contract 两组测试，锁定设置命名空间解析与客户端 bundle 契约，避免后续改动再次破坏新版宿主上的设置页。
安全
粘贴 Token 的路由保留 loopback + loopback Origin + application/json 三重校验，且任何状态响应都不会回显令牌内容（JWT 被脱敏为 [redacted token]）。
测试
新增 19 条导入路由用例（探活顺序、轮换令牌落库、各类拒绝路径、守卫拒绝、脱敏）、2 条积分相关用例，以及设置兼容与 bundle 契约共 187 行测试。用故意破坏源码的方式验证过它们确实有效力：不返回积分（1 条红）、让积分失败中止导入（1 条红）、绕过 loopback 守卫（4 条红）。
已知限制
- 粘贴 Token 不支持密码登录与企业 SSO（二者必须走浏览器交互）。
- 服务端若已把会话标记失效（返回
12153 Offline user session not found），access_token与refresh_token会同时失效，只能重新登录后再粘贴。 - Token 以明文存于本机
$DSH_HOME/.codebuddy-cli-accounts.json（权限600），请勿提交或分享给他人；使用他人 Token 会消耗对方额度。 - 上游每次刷新都会轮换
refresh_token且旧值仍有效，因此同一个 Token 不要被多个客户端同时使用，否则会互相作废。