fix(cli): soften update-check failure UX — warning instead of error, raise timeout to 5s

[ComplexSimply]

What this PR does

Softens how startup update-check failures are presented and gives the check a realistic time budget. On networks where the npm registry is slow or unreachable, Qwen Code used to greet the user with a red ✕ Failed to check for updates. Please check your network or registry configuration. on every launch — alarming wording for something that is a non-blocking background convenience. With this PR the same situation renders as a calm yellow warning that says what actually happened and how to retry: △ Update check skipped (registry unreachable) — run /update to retry.

Three coordinated changes deliver this:

1. Timeout budget raised from 2s to 5s. The 2s budget was aggressive for high-latency mirrors and corporate proxies (per fix(cli): align npm update checks with global registry #7224, npm outdated on Windows consistently takes ~3s). 5s matches comparable CLIs — Claude Code's autoUpdater uses AbortSignal.timeout(5000). The constant is shared by the update-notifier fetch path and the global-npm npm view child-process path, so both get the new budget.
2. Failure severity is now carried on the event. The update-failed event payload gains an optional severity?: 'error' | 'warning' field, defaulting to 'error' so every existing emitter is unaffected. Only the startup background check emits severity: 'warning', which the UI renders as a yellow △ warning. Genuine update install failures keep the red ✕ error, and /update — an explicit user action — also keeps error styling.
3. Failure reasons are classified and surfaced. A new classifier buckets failures into timeout ("registry did not respond within 5s"), offline ("registry unreachable" — matching ENOTFOUND / ECONNREFUSED / EAI_AGAIN / ETIMEDOUT / ENETUNREACH, both on error.code and embedded in npm child-process stderr text), and registry (anything else). All four call sites — startup check, /update slash command, qwen update CLI, and the sandbox update-relaunch path — now include the concrete reason in their message.

i18n: the new strings are translated in all nine locales (en, zh, zh-TW, ca, de, fr, ja, pt, ru), reusing each locale's existing registry/update terminology; the now-unused generic key is removed everywhere. npm run check-i18n passes.

Why it's needed

Users on slow or blocked registries (some regions, corporate proxies) see a red error on every startup even though the app works normally — issue #7049, with a real-world downstream report in #7044 (China, v0.19.11, "升级就报错"). The failure surfacing itself is correct and recent (#6857 fixed a real false-negative bug, shipped via #6887); what's wrong is the presentation: error-red styling and a generic message for a background check that the user never asked for and that doesn't block anything.

This is explicitly not a revert of #6857 / #6887. Failures stay visible ("loud failure"); only the presentation, wording, and time budget change.

Reviewer Test Plan

How to verify

Unreachable registry → offline path (startup, TUI):

npm_config_registry=http://192.0.2.1:1 qwen
# Expected: yellow "△ Update check skipped (registry unreachable) — run /update to retry."
# appears a few seconds after startup; startup itself is not blocked; app fully usable.

Unreachable registry → explicit /update keeps loud error, now with the reason:

npm_config_registry=http://192.0.2.1:1 qwen update
# Expected (stderr, exit code 1):
# "Failed to check for updates (registry unreachable). Please check your network or registry configuration."

Timeout path (slow-but-reachable registry, e.g. a delaying proxy): expected reason becomes registry did not respond within 5s.

No-regression check (#6857): with a normal registry and an older version installed, the update prompt still appears and auto-update still runs.

Unit tests and checks:

cd packages/cli
npx vitest run src/ui/utils/updateCheck.test.ts src/startup/startup-prefetch.test.ts \
  src/utils/handleAutoUpdate.test.ts src/ui/commands/update-command.test.ts \
  src/commands/update.test.ts src/utils/update-relaunch.test.ts   # 134 pass
npm run check-i18n                                                # passes

Key assertions to look at: startup emits severity: 'warning' with the per-reason message (both the resolved-error path and the thrown path); severity: 'warning' renders MessageType.WARNING while absent/explicit-error severity stays MessageType.ERROR (install-failure regression guard); classifier tests cover each network code via error.code and via message text (the global-npm path only surfaces codes in stderr text); a guard test pins FETCH_TIMEOUT_MS ≥ 5000.

Evidence (Before & After)

Before (unreachable registry, red ✕, generic message):

✕ Failed to check for updates. Please check your network or registry
  configuration.

After (same conditions, yellow △, concrete reason + retry hint):

△ Update check skipped (registry unreachable) — run /update to retry.

Live tmux before/after for both the startup TUI and qwen update was captured by the triage bot's independent verification run at b202c0b (see review comments above). The exact user-facing strings are also asserted verbatim in the updated tests.

Negative control (tests genuinely pin the fix): with the test files kept and the production files reverted to origin/main, the six suites fail 17 tests — restoring the fix brings them back to 134/134:

configuration	result
patched production code + new tests	134 pass / 0 fail ✅
origin/main production code + new tests	117 pass / 17 fail (severity missing, old wording, 2s constant)

Blast radius (every other test file importing the touched modules): gemini.test.tsx ✅, standalone-update.test.ts ✅, installationInfo.test.ts ✅; AppContainer.test.tsx runs 114/121 with 7 failures in the unrelated terminal-title feature that fail identically on unpatched origin/main in this environment (TTY-dependent, pre-existing — not introduced by this PR).

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

Linux x86_64, Node.js v22, npm workspaces install; verification via the vitest suites, npm run check-i18n, and eslint on changed files.

Risk & Scope

• Main risk or tradeoff: accidentally downgrading real failures to warnings. Mitigated by design — severity defaults to 'error', only the startup check branch opts into 'warning', and regression tests assert install failures still render as errors. Secondary tradeoff: on broken networks the (now softer) notice can appear up to 3s later than before; the check runs as a post-render deferred task, so startup latency is unaffected.
• Not validated / out of scope: live TUI runs on macOS/Windows locally (covered by CI matrix); the skipped status (development mode etc.) keeps its current styling — changing it is out of scope for Update check: soften timeout UX — warning instead of error, raise timeout budget #7049; no config/setting to customize the timeout (can be a follow-up if maintainers want it).
• Breaking changes / migration notes: none. The event payload extension is backward-compatible (optional field, error default); no public API, settings, or protocol changes.

Linked Issues

• Fixes Update check: soften timeout UX — warning instead of error, raise timeout budget #7049
• Downstream user report: 升级就报错 #7044
• Context (kept, not reverted): /update reports "up to date" on 0.19.9 when 0.19.10 is available on npm registry #6857, fix(cli): apply FETCH_TIMEOUT_MS to /update version check and log fetchInfo results (#6857) #6887
• Timing data motivating the 5s budget: fix(cli): align npm update checks with global registry #7224

Commits: b202c0b (the fix), a233b5f (review follow-up — translations for the six locales flagged in the triage review, so all nine locales now carry the new keys).

中文说明

本 PR 做了什么

软化启动时更新检查失败的呈现方式，并给检查一个更符合现实的时间预算。在 npm registry 缓慢或不可达的网络环境下，Qwen Code 过去每次启动都会显示红色的 ✕ Failed to check for updates. Please check your network or registry configuration.——对一个非阻塞的后台便利功能来说，这种措辞过于惊吓。本 PR 之后，同样场景会渲染为平和的黄色警告，说明实际发生了什么以及如何重试：△ Update check skipped (registry unreachable) — run /update to retry.

三个配套改动：

1. 超时预算从 2 秒提高到 5 秒。 2 秒对高延迟镜像和公司代理过于激进（fix(cli): align npm update checks with global registry #7224 数据显示 Windows 上 npm outdated 稳定耗时约 3 秒）。5 秒与同类 CLI 一致——Claude Code 的 autoUpdater 使用 AbortSignal.timeout(5000)。该常量同时作用于 update-notifier 路径和 global-npm 的 npm view 子进程路径。
2. 失败严重级别随事件携带。 update-failed 事件负载新增可选字段 severity?: 'error' | 'warning'，默认 'error'，所有现有发射点不受影响。只有启动后台检查发出 severity: 'warning'，UI 渲染为黄色 △ 警告。真正的更新安装失败保持红色 ✕ 错误；/update 作为用户显式操作，同样保持错误样式。
3. 失败原因分类并呈现。 新的分类器将失败分为超时（"registry did not respond within 5s"）、离线（"registry unreachable"——匹配 ENOTFOUND / ECONNREFUSED / EAI_AGAIN / ETIMEDOUT / ENETUNREACH，同时匹配 error.code 和 npm 子进程 stderr 文本）和registry 错误（其他情况）。四个调用点——启动检查、/update 斜杠命令、qwen update CLI、沙箱 update-relaunch 路径——的消息现在都包含具体原因。

i18n：新字符串已翻译到全部九个语言（en、zh、zh-TW、ca、de、fr、ja、pt、ru），沿用各语言现有的 registry/更新术语；已无用的旧通用 key 从所有语言中移除。npm run check-i18n 通过。

为什么需要

慢速或被屏蔽 registry 环境的用户（部分地区、公司代理）每次启动都会看到红色错误，尽管应用完全正常——issue #7049，下游真实用户报告见 #7044（中国用户，v0.19.11，"升级就报错"）。失败显式化本身是正确且新近的修复（#6857 修复了真实的假阴性 bug，经 #6887 发布）；问题在于呈现方式：对一个用户未主动请求、也不阻塞任何操作的后台检查使用了错误级红色样式和笼统文案。

本 PR 明确不是 #6857 / #6887 的回退。 失败保持可见（"loud failure"）；只改变呈现方式、措辞和时间预算。

评审验证方案

如何验证

不可达 registry → 离线路径（启动 TUI）：npm_config_registry=http://192.0.2.1:1 qwen，预期启动数秒后出现黄色 △ Update check skipped (registry unreachable) — run /update to retry.，启动不被阻塞，应用完全可用。

不可达 registry → 显式 /update 保持醒目错误并带原因：npm_config_registry=http://192.0.2.1:1 qwen update，预期 stderr 输出 Failed to check for updates (registry unreachable). Please check your network or registry configuration.，退出码 1。

超时路径（可达但缓慢的 registry，如延迟代理）：预期原因变为 registry did not respond within 5s。

无回归检查（#6857）：正常 registry 下安装旧版本，更新提示仍然出现，自动更新仍然执行。

单元测试与检查：packages/cli 下运行六个受影响测试文件共 134 个用例全部通过；npm run check-i18n 通过。

重点断言：启动路径发出 severity: 'warning' 及按原因区分的消息（resolved-error 与 thrown 两条路径）；severity: 'warning' 渲染 MessageType.WARNING，缺省/显式 error 保持 MessageType.ERROR（安装失败回归保护）；分类器测试覆盖每个网络错误码的 error.code 与消息文本两种匹配方式；守卫测试锁定 FETCH_TIMEOUT_MS ≥ 5000。

证据（前后对比）

改动前（不可达 registry，红色 ✕，笼统消息）与改动后（同等条件，黄色 △，具体原因 + 重试提示）见上方英文部分。triage bot 在 b202c0b 的独立验证运行中捕获了启动 TUI 和 qwen update 的实机 tmux 前后对比（见上方评审评论）。用户可见字符串也在更新后的测试中逐字断言。

测试平台

Linux ✅（本地：vitest 套件、check-i18n、changed-files eslint）；macOS / Windows ⚠️（由 CI 矩阵覆盖）。

环境（可选）

Linux x86_64，Node.js v22，npm workspaces 安装。

风险与范围

• 主要风险/权衡：把真正的失败误降级为警告。设计上已规避——severity 默认 'error'，仅启动检查分支主动选择 'warning'，回归测试断言安装失败仍渲染为错误。次要权衡：坏网络下（现已软化的）提示最多比之前晚 3 秒出现；检查在渲染后延迟任务中运行，启动延迟不受影响。
• 未验证/范围外：macOS/Windows 本地实机 TUI（由 CI 矩阵覆盖）；skipped 状态（development mode 等）保持现有样式——修改它超出 Update check: soften timeout UX — warning instead of error, raise timeout budget #7049 范围；未提供超时配置项（若维护者需要可作为后续跟进）。
• 破坏性变更/迁移说明：无。事件负载扩展向后兼容（可选字段、error 默认值）；无公共 API、设置或协议变更。

关联 Issue

• Fixes Update check: soften timeout UX — warning instead of error, raise timeout budget #7049；下游用户报告 升级就报错 #7044；保留（非回退）上下文 /update reports "up to date" on 0.19.9 when 0.19.10 is available on npm registry #6857、fix(cli): apply FETCH_TIMEOUT_MS to /update version check and log fetchInfo results (#6857) #6887；支撑 5 秒预算的耗时数据 fix(cli): align npm update checks with global registry #7224

提交：b202c0b（修复本体）、a233b5f（评审跟进——补齐 triage 评审指出的六个语言翻译，九个语言现已全部携带新 key）。

补充证据（负向控制）：保留测试文件、将生产代码还原到 origin/main 时，六个套件失败 17 个用例（severity 缺失、旧文案、2 秒常量）；恢复修复后回到 134/134 全绿——证明测试确实钉住了修复。波及面：导入被改模块的其余测试文件（gemini.test.tsx、standalone-update.test.ts、installationInfo.test.ts）全部通过；AppContainer.test.tsx 114/121 通过，7 个失败位于无关的终端标题功能，在未修复的 origin/main 上同样失败（依赖 TTY 的预存环境问题，非本 PR 引入）。

🤖 Generated with Claude Code

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓ — headings are all present. The "Tested on" table and "Evidence" sections are unfilled, but the top description and linked issue provide enough context.

Problem: observed UX issue with solid evidence. Issue #7049 documents users on slow/blocked registries seeing an alarming red ✕ Failed to check for updates on every startup, confirmed by downstream report #7044 (user in China on v0.19.11) and data from #7224 showing npm outdated consistently ~3s on Windows, exceeding the 2s budget. This is a real, reproduced problem — not theoretical hardening.

Direction: aligned. This is a UX refinement of how update-check failures are surfaced, explicitly not a revert of #6857/#6887 — the loud-failure direction stays. The issue was opened by a collaborator and triaged as "community PRs welcome." CHANGELOG: no direct reference, but the area (update check UX) is clearly relevant.

Size: not applicable — all changes are in packages/cli/src/, no core module paths. 149 production lines + 176 test lines.

Approach: scope feels right — the PR maps 1:1 to the three asks in #7049 (raise timeout, soften severity, differentiate failure reason). No drive-by refactors or unrelated changes. One note: the old generic i18n key is dropped from ca/de/fr/ja/pt/ru but the new parameterized keys are only added to en/zh/zh-TW, so those six locales will fall back to English until translated. Not a blocker — just worth knowing.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓ — 所有标题均存在。"Tested on"表格和"Evidence"部分未填写，但顶部描述和关联 issue 提供了足够的上下文。

问题：已观测到的 UX 问题，有充分证据。Issue #7049 记录了慢速/被屏蔽 registry 的用户每次启动时看到红色 ✕ Failed to check for updates 错误，下游报告 #7044（中国用户，v0.19.11）和 #7224 的数据（Windows 上 npm outdated 稳定 ~3s，超过 2s 预算）均证实。这是真实的、已复现的问题，不是理论性加固。

方向：对齐。这是对更新检查失败展示方式的 UX 优化，明确不是 #6857/#6887 的回退——失败可见性保持不变。Issue 由 collaborator 开启，triage 为"欢迎社区 PR"。

规模：不适用——所有改动在 packages/cli/src/，不涉及核心模块路径。149 行生产代码 + 176 行测试代码。

方案：范围合理——PR 与 #7049 的三个要求一一对应（提高超时、降低严重性、区分失败原因）。无顺手重构或无关改动。注意：旧的通用 i18n key 从 ca/de/fr/ja/pt/ru 中移除，但新的参数化 key 仅添加到 en/zh/zh-TW，这六个语言将回退到英文，直到翻译完成。不是阻塞项。

进入代码审查 🔍

— Qwen Code · qwen3.7-max

_{Reviewed at b202c0b2b781bc71e961416105bb6dec8cfcf16f · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code Review

Independent proposal: Given #7049, I'd (1) raise FETCH_TIMEOUT_MS to 5s, (2) add a severity field to the update-failed event so the startup check can emit warning while install failures stay error, (3) classify errors into timeout/offline/registry buckets for specific messages, (4) thread the reason through /update and update-relaunch.

Comparison: The PR matches this almost exactly. The implementation is clean:

• classifyUpdateCheckError correctly handles UpdateCheckTimeoutError, network error codes (both on error.code and embedded in message text — smart for npm child-process stderr), and falls back to registry. The NETWORK_ERROR_CODES list covers the common cases (ENOTFOUND, ECONNREFUSED, EAI_AGAIN, ETIMEDOUT, ENETUNREACH).
• describeUpdateCheckFailure maps classifications to i18n strings with a sensible default timeoutMs parameter.
• The severity field is backward-compatible — existing update-failed emissions in handleAutoUpdate.ts (actual install failures) omit it and correctly default to MessageType.ERROR.
• Mock updates use the importOriginal pattern, necessary because new exports were added to updateCheck.ts.

No critical blockers or AGENTS.md violations found. 134 unit tests pass across all 6 changed test files.

One minor note: the old generic i18n key is dropped from ca/de/fr/ja/pt/ru but the new parameterized keys are only added to en/zh/zh-TW — those six locales fall back to English. Not a blocker.

Before (installed qwen v0.20.0, unreachable registry)

Startup update check — red ✕ error, generic message:

  ┌──────────────────────────────────────────────────────────────────────────┐
  │ >_ Qwen Code (v0.20.0)                                                   │
  │                                                                          │
  │ API Key | qwen3.8-max-preview (/model to change)                         │
  │ /tmp/triage-test-170127                                                  │
  └──────────────────────────────────────────────────────────────────────────┘
  Tips: Add a QWEN.md file to give Qwen Code persistent project context.
  ✕ Failed to check for updates. Please check your network or registry
    configuration.

/update command — generic error:

$ npm_config_registry=http://192.0.2.1:1 qwen update 2>&1
Failed to check for updates. Please check your network or registry configuration.

After (this PR, unreachable registry)

Startup update check — yellow △ warning, specific reason, actionable hint:

  ┌──────────────────────────────────────────────────────────────────────────┐
  │ >_ Qwen Code (v0.20.0)                                                   │
  │                                                                          │
  │ API Key | qwen3.8-max-preview (/model to change)                         │
  │ /tmp/triage-test-170127                                                  │
  └──────────────────────────────────────────────────────────────────────────┘
  Tips: Type / to open the command popup; Tab autocompletes slash commands and
   saved prompts.

  ● Auto mode enabled.
       An LLM classifier evaluates each tool call — safe actions auto-approve,
       risky ones are blocked. Exit: Shift+Tab or /approval-mode default.
  △ Update check skipped (registry error) — run /update to retry.

/update command — specific reason included:

$ npm_config_registry=http://192.0.2.1:1 node dist/cli.js update 2>&1
Failed to check for updates (registry error). Please check your network or registry configuration.

The before/after confirms the PR delivers exactly what #7049 asked for: the alarming red ✕ error becomes a soft yellow △ warning with the concrete failure reason and an actionable retry hint.

中文说明

代码审查

独立方案： 针对 #7049，我会 (1) 将 FETCH_TIMEOUT_MS 提高到 5s，(2) 给 update-failed 事件添加 severity 字段，使启动检查可以发出 warning 而安装失败保持 error，(3) 将错误分类为 timeout/offline/registry 以提供具体消息，(4) 在 /update 和 update-relaunch 中传递原因。

对比： PR 几乎完全匹配。实现干净：

• classifyUpdateCheckError 正确处理 UpdateCheckTimeoutError、网络错误码（同时在 error.code 和消息文本中匹配——对 npm 子进程 stderr 很聪明），并回退到 registry。
• severity 字段向后兼容——handleAutoUpdate.ts 中现有的 update-failed 发射（实际安装失败）省略它并正确默认为 MessageType.ERROR。

无关键阻塞项或 AGENTS.md 违规。134 个单元测试全部通过。

测试证据

Before：红色 ✕ 错误，通用消息。After：黄色 △ 警告，具体原因，可操作的重试提示。与 #7049 的要求完全一致。

— Qwen Code · qwen3.7-max

_{Reviewed at b202c0b2b781bc71e961416105bb6dec8cfcf16f · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 4/5 — clean, well-scoped fix that delivers exactly what #7049 asked for; only nit is the i18n fallback for six locales.

Stepping back: this PR solves a real, user-reported problem (red ✕ error on every startup for users on slow registries), the implementation is straightforward (two small functions + a severity field), every change in the diff maps directly to one of the three asks in the issue, and the before/after tmux output confirms it works as promised. The code is the kind I'd thank the author for in six months — clear naming, good comments where the why matters, comprehensive tests.

The only reservation is minor: ca/de/fr/ja/pt/ru lose their translated error message and fall back to English until someone adds the new parameterized keys. Not worth blocking over.

Approving. ✅

中文说明

置信度：4/5 — 干净、范围合理的修复，完全实现了 #7049 的要求；唯一的小问题是六个语言的 i18n 回退。

总结：这个 PR 解决了一个真实的用户报告问题（慢速 registry 用户每次启动看到红色 ✕ 错误），实现简单（两个小函数 + 一个 severity 字段），diff 中的每个改动都直接对应 issue 的三个要求之一，before/after tmux 输出确认了效果。代码清晰，命名好，注释到位，测试全面。

唯一的保留意见很小：ca/de/fr/ja/pt/ru 失去了翻译的错误消息，回退到英文。不值得阻塞。

批准。✅

— Qwen Code · qwen3.7-max

_{Reviewed at b202c0b2b781bc71e961416105bb6dec8cfcf16f · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[ComplexSimply]

Thanks for the review! Follow-up pushed:

• a233b5f adds the translated update-check failure keys for ca / de / fr / ja / pt / ru flagged in the review, reusing each locale's existing registry/update terminology — all nine locales now carry the new strings, and npm run check-i18n passes.
• PR description has been updated to fully fill the template, including a reviewer test plan, a negative-control run (the six suites fail 17 tests when the production files are reverted to origin/main with the new tests kept, and return to 134/134 with the fix), and blast-radius verification over every other test file importing the touched modules.

[ComplexSimply]

@qwen-code /triage

[yiliang114]

Thanks for working on this. The 5s timeout and turning the startup failure into a warning address the reported problem. The current diff goes beyond that by introducing a three-way error taxonomy and threading it through qwen update, /update, and the relaunch path. Could we narrow this PR to the startup check only, and leave the explicit update flows unchanged? That would make the behavior easier to verify and keep #7049 focused. I left a few concrete comments inline. Please also fill in the reviewer test plan/risk sections and use Fixes #7049.

[yiliang114]

The report in #7049 is about the non-blocking startup check. This changes the explicit qwen update failure contract as well, and the same propagation appears in /update and the relaunch path. Could we leave those paths unchanged in this PR and keep the change at the startup boundary?

[yiliang114]

If we keep a specific failure reason for startup, could we limit it to UpdateCheckTimeoutError plus a generic fallback? The real errors do not reliably match this taxonomy: Node 22 fetch puts ENOTFOUND under error.cause, while execFile({ timeout }) returns code: null, killed: true, and signal: SIGTERM. Both currently become registry error.

[yiliang114]

This should be toBe(5000). >= 5000 would still pass if this accidentally became 50 seconds, and the other timeout tests advance by the same constant, so they would not catch that regression either.

[ComplexSimply]

macOS Apple Silicon verification (2026-07-21)

Tested commit a233b5f5b0f8d36982394460a6268e5c72750867 on:

• macOS 26.5.2 (Build 25F84), Darwin arm64
• MacBook Pro, Apple M4 Pro, 48 GB RAM
• Node.js v22.22.0, npm 10.9.4

Passed

• npm ci completed successfully, including the repository prepare build and bundle.
• npm run build -- --cli-only passed.
• cd packages/cli && npm run typecheck passed.
• npm run check-i18n passed.
• The six affected Vitest suites passed: 6 files, 134/134 tests.
• Darwin arm64 native packages installed and loaded successfully: @lydell/node-pty and @teddyzhu/clipboard.
• A local delaying registry exercised the timeout path: exit code 1 after about 5.5s with:

Failed to check for updates (registry did not respond within 5s). Please check your network or registry configuration.

• A real PTY startup reached the interactive UI without being blocked and rendered the new warning row:

△ Update check skipped (registry error) — run /update to retry.

Finding: nested network errors are classified as registry error

The unreachable-registry test plan does not produce the expected registry unreachable reason on this macOS/Node 22 setup for the update-notifier path:

npm_config_registry=http://127.0.0.1:65534 node dist/cli.js update

Actual result:

Failed to check for updates (registry error). Please check your network or registry configuration.

The underlying error shape is:

{
  "classification": "registry",
  "name": "TypeError",
  "message": "fetch failed",
  "causeMessage": "connect ECONNREFUSED 127.0.0.1:65534",
  "causeCode": "ECONNREFUSED"
}

classifyUpdateCheckError() currently checks only the top-level error's code and message; Node's fetch places ECONNREFUSED in error.cause. The startup TUI shows the same registry error classification.

Suggested follow-up: inspect a bounded Error.cause chain (code and message) and add a test for TypeError('fetch failed', { cause: errnoError }). The global-npm path on this setup retries until the outer 5s budget and is correctly reported as a timeout.

Conclusion: macOS build, typecheck, i18n, native-module loading, unit tests, timeout handling, and non-blocking warning UX pass. I would keep macOS at ⚠️ rather than ✅ until the unreachable-registry classification gap is fixed or explicitly accepted.

[wenshao]

Code review — update-check failure UX (#7049)

Reviewed the full diff. This is a well-scoped, well-tested change. It does exactly what it says: softens the startup background check to a yellow △ warning with a concrete reason, keeps genuine install failures and explicit /update actions as red ✕ errors, and raises the fetch budget 2s → 5s. Below is what I verified plus a few optional nits.

What it does

• Raises FETCH_TIMEOUT_MS 2000 → 5000 (shared by both the update-notifier and global-npm child-process paths).
• Adds an optional severity?: 'error' | 'warning' to the update-failed payload, defaulting to error; only the startup check opts into warning, which handleAutoUpdate renders as MessageType.WARNING.
• Adds classifyUpdateCheckError / describeUpdateCheckFailure to bucket failures into timeout / offline / registry and surface the reason at all four call sites (startup, /update, qwen update, sandbox relaunch).
• Full i18n across all 9 locales; the old generic key is removed everywhere.

Correctness — verified

• .code inspection is sound. checkForUpdatesDetailed normalizes with e instanceof Error ? e : new Error(String(e)), so result.error is always a real Error and classifyUpdateCheckError can read .code and .message safely; the non-Error path falls through to 'registry' (covered by a test).
• Install failures stay loud. The three update-failed emits in handleAutoUpdate.ts (auto-update .catch, non-zero exit, spawn error) emit no severity, so they keep MessageType.ERROR. The new render test pins both directions (warning → WARNING, explicit error → ERROR), which is a good regression guard.
• Dual matching is justified. Checking network codes on both error.code and error.message is needed because the global-npm path only surfaces the code inside child-process stderr text — the comment and tests both capture this.
• i18n is complete. Exactly 9 locale files exist and all 9 are updated; check-i18n tracks missing/extra keys, so removing the old key + adding the new ones consistently is required and done.

Optional nits (none blocking)

1. describeUpdateCheckFailure ignores the timeout carried on the error. For the timeout branch it recomputes seconds from the module constant FETCH_TIMEOUT_MS rather than UpdateCheckTimeoutError.timeoutMs. They're always identical today so the message is correct, but reading the error's own timeoutMs (when present) would keep the text truthful if the two ever diverge.
2. ETIMEDOUT is bucketed as offline ("registry unreachable"). A socket-level connect ETIMEDOUT is arguably closer to the timeout bucket ("did not respond within 5s") than to unreachable. This only affects low-level socket timeouts — the app-level UpdateCheckTimeoutError is matched first — so it's a minor semantic call, and "unreachable" is still reasonable.
3. The update-failed payload shape is duck-typed. updateEventEmitter is a bare EventEmitter, so the payload ({ message?, severity? }) is now declared inline in two spots (emitter + handler) with no shared type to keep them in sync. Pre-existing pattern, but adding severity was a natural moment to introduce a typed payload so the emit/handle contract can't silently drift.
4. Wording: "Update check skipped (...)" reads slightly off since the check actually ran and failed rather than being skipped. I get the intent to soften; "Update check failed (...) — run /update to retry." might be more accurate while staying calm. Purely product wording — non-blocking.
5. The startup catch also softens unexpected (non-network) throws to warning/"registry error". Fine for best-effort background work, and it still re-throws for logging — just noting the downgrade applies to programming errors too.

Risk & tests

Low risk. The one real hazard — downgrading genuine failures to warnings — is contained by the error default plus the install-failure render tests. Test coverage is strong: per-code classification via both code and message text, a FETCH_TIMEOUT_MS ≥ 5000 guard, both startup emit paths, and a negative control showing 17 failures when production is reverted. Nicely done.

Overall: LGTM. The nits above are optional and can be follow-ups.

---

_{🤖 Reviewed with Claude Code · model: Claude Opus 4.8}

[qwen-code-ci-bot]

No issues found. LGTM! ✅

— qwen3.7-max via Qwen Code /review

[yiliang114]

The core here — softening the startup check to a warning and raising the fetch budget to 5s — is right, and it doesn't regress anything: worst case the message stays as generic as it was before. Clearing the earlier change request.

Two things aren't fully solved, but neither blocks this, so tracking them as a follow-up in #7423:

• The timeout/offline taxonomy doesn't match the real error shapes it's meant to catch, so both degrade to the generic "registry error" (repro in the issue).
• Scope: the qwen update / relaunch failure contract changed beyond what #7049 needs.

LGTM.

[ZijianZhang989]

No issues found. LGTM! ✅

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

Released in v0.20.1.