本文要点
- 官方 GitHub Release 的 published_at 为 2026-09-10T08:04:06Z，即北京时间 16:04:06；本页不把 tag 创建时间冒充发布时间。
- v0.3.0 会在刷新后的 session load 中保留 pending permission/question，但官方没有承诺恢复升级前已丢失的确认项。
- Windows 修复会在每个 PTY 结束后释放 node-pty conout worker；应以新建终端、结束任务和退出应用后的进程与句柄表现验收。
- web-shell 的 workspace provider 增加自诊断并在 root retry 时 reload，仍须核对实际工作区根目录和文件权限。
- 官方 Release 提供 Windows x64、macOS arm64/x64、Linux AppImage/deb、SHA256SUMS.txt 与签名文件；系统架构或校验不一致时立即停止安装。
- PRODUCT_FIT=CONDITIONAL_NETWORK_ONLY：版本、权限状态、PTY 释放和工作区 root 错误不是代理问题；只有 DNS、TLS、407 或连接超时有证据时才比较出口。
发生了什么：一次同时触及权限、终端、错误与工作区的桌面版更新
QwenLM 在官方 GitHub Release 发布 Qwen Code Desktop v0.3.0。Release API 记录的发布时间是 2026-09-10T08:04:06Z；版本对应 tag `desktop-v0.3.0` 和提交 `b74592785bff038a1e3b5c533d20ae49e549ab2a`。本次重点不是新模型，而是桌面工作流的状态保存与故障可诊断性。
官方变更包括：刷新 session 后保留待处理的 permission/question、保留 Responses stream 的错误细节、Windows 每个 PTY 结束后释放 node-pty conout worker，以及让 web-shell workspace provider 能自诊断并在 root retry 时重新加载。官方没有公布受影响用户数，也没有保证这些修复覆盖所有第三方 provider、旧会话或自定义安装方式；这些范围均为 UNKNOWN。
先判断是否命中：四类症状不要混成一个“桌面版坏了”
第一类是刷新或恢复会话后，原本等待用户确认的文件、命令权限或澄清问题消失；第二类是 Windows 终端任务结束后仍残留 worker、退出变慢或连续开关 PTY 后资源持续增长；第三类是 Responses 流失败时只剩模糊错误，无法判断认证、参数、限额或上游状态；第四类是 web-shell 无法识别工作区 root，重试后仍停在旧状态。
记录当前桌面版号、操作系统与架构、会话 ID、工作区绝对路径、触发步骤、错误原文、时间、是否刷新，以及任务是否可能已执行。权限问题要记录待确认动作；终端问题记录任务开始和结束；流式错误保存 request/run ID；工作区问题保存 root 与文件权限。没有这些证据时，不要用升级成功来倒推旧问题的根因。
升级前准备：保护会话、配置与未确认动作
先停止会写文件、提交代码或调用外部系统的新任务，等待已经开始的动作进入可核对终态。把仍在等待的 permission/question 逐项截图或记账，保存未提交差异、重要对话导出、工作区路径与用户配置；如果动作状态未知，先核对文件和外部系统，不能因刷新后确认框消失就直接重跑。
选择一个可复现但不会产生外部副作用的样例：只读命令的权限询问、一条可取消的长终端任务、一条会返回明确测试错误的 Responses 请求，以及一个非生产工作区 root。为当前版本记录同一组结果，作为升级后的对照。
从官方 Release 选包并核验，不猜自动更新路径
官方 v0.3.0 Release 提供 Windows x64 setup.exe、macOS arm64/x64 dmg、Linux amd64 AppImage/deb，以及 `SHA256SUMS.txt` 和对应 `.sig` 文件。只从该 Release 的 Assets 选择与系统和 CPU 架构匹配的文件；页面或应用没有明确显示自动更新完成时，不要仅凭重启判断版本已切换。
下载后先按 `SHA256SUMS.txt` 校验文件，再核对签名文件和来源 URL。关闭桌面应用前确认没有仍在运行或状态未知的任务，然后按组织允许的方式安装。安装器名称、大小、哈希、安装时间和旧版本号都要留档；架构不匹配、校验失败、签名异常、来源跳转到非官方域名或安全软件告警时立即停手。
用同一组动作验收四项修复
权限验收：新建测试会话触发一次只读权限询问和一个澄清问题，在不批准的情况下刷新，再确认两项仍待处理且不会重复执行。Windows PTY 验收：连续创建并正常结束若干短任务，确认退出后不再持续残留 conout worker、应用仍能创建新终端；不要用强杀进程冒充正常释放。
Responses 验收：使用测试请求触发一个可预期错误，确认界面或日志保留足以区分认证、参数、限额和服务状态的细节，但不要把敏感 token 写入日志。工作区验收：从错误 root 启动一次受控重试，确认 provider 给出可诊断信息并在选择正确 root 后 reload；随后验证只读访问范围，没有扩大文件写权限。
失败分层、停手与回滚条件
升级后仍丢待确认项，先区分是否为升级前旧会话、刷新方式差异或动作已经结束；仍残留 PTY，记录 Windows 版本、父子进程和最小复现；流错误仍模糊，保留 provider、model、request/run ID 与原始状态；root 重试无效，核对绝对路径、目录存在性、文件权限和 workspace provider 日志。不要跨层反复重装。
发现安装包校验或签名异常、会话内容丢失、权限默认值扩大、写入动作重复执行、终端资源持续增长，或关键工作区无法打开时，立即停止扩大。若组织保留了已验证的旧安装包与配置快照，可回滚到旧版本并继续使用人工确认或受限只读流程；回滚不能恢复已丢数据，状态未知的外部动作仍须单独对账。
网络边界：先修版本与权限，只有连接证据才比较出口
刷新后 permission/question 丢失、Windows node-pty worker 未释放、Responses 错误细节缺失和 workspace root reload 都是客户端状态或版本行为，不应通过换 IP、关闭 TLS 校验或扩大代理权限处理。固定出口也不能替代正确安装包、文件权限或用户确认。
只有访问 GitHub Release、模型 API 或组织服务时出现 DNS 解析失败、TLS 握手错误、代理 407、连接超时，或同一账号与配置在不同出口稳定复现差异，才参考<a href="/resources/proxy-connection-troubleshooting-checklist">代理连接故障分层清单</a>。先保留 request/run ID 与目标域名；连接恢复后若症状仍在，回到版本、会话、权限和工作区层。
资料来源
常见问题
Qwen Code Desktop v0.3.0 什么时候发布？
官方 GitHub Release API 的 published_at 是 2026-09-10T08:04:06Z，即北京时间 16:04:06。tag 创建时间更早，不能把创建时间当成正式发布时间。
刷新后权限确认还会消失吗？
v0.3.0 的官方变更是让 refreshed session load 保留 pending permission/question。仍应先在非生产会话复测；官方没有承诺恢复升级前已经丢失的确认项。
Windows 终端卡住是否一定由 node-pty 引起？
不一定。v0.3.0 修复的是每个 PTY 后释放 conout worker；还要结合父子进程、任务终态、日志和可重复步骤，排除命令自身、杀毒软件或文件权限问题。
应该下载哪个安装包？
从官方 v0.3.0 Release Assets 按系统和架构选择 Windows x64 setup.exe、macOS arm64/x64 dmg，或 Linux amd64 AppImage/deb，并使用 SHA256SUMS.txt 与签名文件核验。
更新后工作区 root 仍打不开怎么办？
保存 provider 的自诊断信息，核对绝对路径、目录存在性和文件权限，再在正确 root 上执行受控 retry/reload。不要通过扩大整个磁盘权限或重复重装掩盖路径错误。
换固定 IP 能修复这些问题吗？
不能修复客户端状态、权限保存、PTY 释放或 root reload。只有 DNS、TLS、407、连接超时或稳定出口差异有证据时，网络对比才有意义。