fix(cli): prevent silent VP-mode crash by adding uncaughtException handler and error visibility

[chiga0]

What this PR does

Adds a process.on('uncaughtException') handler and strengthens error visibility in VP (alternate-screen) mode. Related to #7971 #7972 #7779 #7781.

This PR does not claim to fix the crashes reported in those issues — it ensures that the next time a crash occurs, the error is captured in the debug log and visible on the terminal, so the actual root cause can be identified and fixed.

Why it's needed

Users report the CLI exiting silently during model streaming with VP mode enabled (ui.useTerminalBuffer: true) — no error message, no debug log entry, empty stderr.

Investigation of a real crash session (9b4af1de) confirmed:

• The model stream stopped mid-thought (135 chars accumulated), then the process exited
• No [ERROR], [FATAL], or exception entry in the debug log
• No uncaughtException handler exists anywhere in packages/cli/src
• PR fix(cli): surface unhandled rejections and render errors instead of swallowing them #7406's ErrorBoundary and unhandledRejection handler are present in 0.21.1 but only cover React render errors and promise rejections — synchronous exceptions bypass both

The silence mechanism: in VP mode, Node's default uncaught-exception stack trace goes to stderr → alternate screen buffer → discarded when teardown writes ?1049l. The user sees their shell prompt with no trace of what happened.

Changes

Core fix: uncaughtException handler

• setupUncaughtExceptionHandler(sessionId) in gemini.tsx
• Synchronous fs.appendFileSync to the debug log (async debugLogger.error() would be abandoned by process.exit)
• Leaves the alternate screen (?1049l) before writing to stderr, so the error is visible on the main screen
• Exits with code 1

ErrorBoundary (port of #7406 for internal sync)

• ErrorBoundary.tsx with normalizeError, fallback prop, onError callback, reset recovery
• Wraps AppWrapper with [FATAL_RENDER_ERROR] debug logging + 5s auto-exit
• consumeLastRenderError() echoes the error to stderr after unmount leaves the alternate screen

VP teardown fixes

• disableKittyProtocol() moved after instance.unmount() so the Kitty pop lands on the main screen buffer, not the alternate screen (bug(cli): VP teardown can leave Kitty keyboard flags enabled on the main screen #7779)
• Removed SIGTERM/SIGINT handlers from kittyProtocolDetector.ts that raced with the main signal handlers
• Added SIGHUP handler alongside SIGTERM/SIGINT (bug(cli): SIGTERM and SIGHUP can leave VP terminal modes active #7781)

MarkdownDisplay defense

• ThinkMessage/ThinkMessageContent wrapped with per-item ErrorBoundary — partial markdown during thought streaming degrades to plain text instead of crashing the VP tree

How to verify the fix works

After this PR, any crash will leave a trace:

# Search debug logs for the crash
grep -E "UNCAUGHT_EXCEPTION|FATAL_RENDER_ERROR|Unhandled Promise" ~/.qwen/debug/<session-id>.txt

Marker	Error type	Next step
[UNCAUGHT_EXCEPTION]	Synchronous exception	Stack trace points to the exact code
[FATAL_RENDER_ERROR]	React render error	Component stack points to the component
Unhandled Promise Rejection	Async rejection	Reason + stack point to the uncaught promise

No --debug flag needed — the debug log file is written by default.

Reviewer Test Plan

1. cd packages/cli && bun run typecheck — passes
2. npx vitest run src/ui/components/shared/ErrorBoundary.test.tsx — 7 tests pass
3. npx vitest run src/ui/components/shared/VirtualizedList.test.tsx src/ui/components/shared/ScrollableList.test.tsx — 29 tests pass (no regression)

Risk & Scope

• The uncaughtException handler calls process.exit(1) — this is intentional. Without it, Node.js would keep the process alive in an undefined state after a synchronous exception.
• The ErrorBoundary wrapping AppWrapper intercepts errors before Ink's internal boundary. In non-VP mode this changes the error display from Ink's ErrorOverview to our fallback (same information, slightly different UI).
• The Kitty teardown reordering (bug(cli): VP teardown can leave Kitty keyboard flags enabled on the main screen #7779) and SIGHUP handler (bug(cli): SIGTERM and SIGHUP can leave VP terminal modes active #7781) are independent fixes bundled here because they share the same teardown code path.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[chiga0]

Closing — branch was based on internal main, not upstream. Re-opening with a clean branch.

[qwen-code-ci-bot]

Thanks for the PR, and for the detailed investigation into the silent VP-mode crashes — the crash session analysis (9b4af1de) and the stderr-to-alternate-screen explanation are genuinely useful.

Template: mostly there, but missing the ## Linked Issues section and the Chinese <details> translation. The issues are referenced inline (#7971 #7972 #7779 #7781), so this is minor.

Problem: real and observed. Users are hitting silent exits during model streaming in VP mode with no error trace — the linked issues and the debug log analysis confirm this. The silence mechanism (stderr → alternate screen → discarded on ?1049l) is well explained.

Direction: aligned. Error visibility for silent crashes is squarely within scope.

Approach — this is the big one. This PR carries 250 commits and 1,149 changed files (+237K / −26K lines) from what appears to be an internal DataWorks fork that has diverged substantially from upstream main. The actual fix described in the PR body touches about four files (gemini.tsx, ErrorBoundary.tsx, ErrorBoundary.test.tsx, kittyProtocolDetector.ts), but the diff also includes fork-specific infrastructure (.aoneci/, .fork/ patches, branding, internal CI scripts, DataWorks features, channel packages, and extensive changes across packages/core and packages/cli).

More importantly, upstream main already has most of what this PR adds:

• ErrorBoundary.tsx exists upstream (with sanitizeTerminalText, used in TranscriptView and startInteractiveUI.tsx)
• An uncaughtException handler exists in cli.ts (with PTY-race suppression)
• startInteractiveUI.tsx already wraps AppWrapper with ErrorBoundary + [FATAL_RENDER_ERROR] logging + 5s auto-exit — the exact pattern the PR describes
• Kitty teardown (disableKittyProtocol()) already runs after instance.unmount() in the upstream cleanup chain

The fork's gemini.tsx inlines the interactive UI setup, while upstream delegates to startInteractiveUI.tsx — so the PR's changes to gemini.tsx don't map onto upstream's architecture.

The genuinely new ideas that upstream doesn't have yet:

1. Sync debug-log write inside the uncaughtException handler (upstream's cli.ts handler only writes to stderr)
2. Leaving the alternate screen (?1049l) before writing the error to stderr, so it's visible on the main screen
3. consumeLastRenderError() to echo render errors to stderr after unmount
4. SIGHUP handler alongside SIGTERM/SIGINT
5. Removing the SIGTERM/SIGINT handlers from kittyProtocolDetector.ts that race with the main signal handlers (these still exist upstream)

These are worth upstreaming — but as a focused PR rebased on current main, touching cli.ts and startInteractiveUI.tsx rather than the fork's gemini.tsx.

Size: 253 production core-module files touched. The vast majority is fork divergence, not the fix. The 1000+ production-line advisory applies many times over.

Risk: 22 high-risk paths matched (geminiChat, openaiContentGenerator, shellExecutionService, mcp-client, LspServerManager, relaunch, acp-integration, shell.ts) — all from the fork divergence, not the fix itself. These paths have the strongest correlation with post-merge reverts in this repo.

CI: no build/test/lint checks have run on this commit — only bot orchestration. Without CI, there's no evidence the diff compiles against upstream.

I'd suggest closing this PR and opening a new one with just the five incremental improvements listed above, rebased on current main. The underlying investigation is solid and the ideas are good — they just need to land in the right files on the right base.

Flagging for @wenshao's attention given the scope and the core-module breadth.

中文说明

感谢这个 PR，也感谢对 VP 模式静默崩溃的详细调查——crash session 分析（9b4af1de）和 stderr 写入 alternate screen 被丢弃的解释非常有价值。

模板： 基本完整，缺少 ## Linked Issues 独立章节和中文 <details> 翻译。Issues 已在正文中引用（#7971 #7972 #7779 #7781），问题不大。

问题： 真实且已观测到。用户在 VP 模式下模型流式输出时遇到静默退出，无任何错误痕迹——关联的 issues 和 debug log 分析证实了这一点。

方向： 对齐。崩溃错误可见性完全在项目范围内。

方案——这是核心问题。 这个 PR 包含 250 个 commit、1149 个变更文件（+237K / −26K 行），来自一个与上游 main 大幅分叉的内部 DataWorks fork。PR 描述中的实际修复只涉及约四个文件，但 diff 还包括 fork 专属基础设施（.aoneci/、.fork/ 补丁、品牌、内部 CI 脚本、DataWorks 功能、channel 包等）。

更关键的是，上游 main 已经有了这个 PR 添加的大部分内容：

• ErrorBoundary.tsx 已存在上游
• cli.ts 中已有 uncaughtException handler
• startInteractiveUI.tsx 已用 ErrorBoundary 包裹 AppWrapper + [FATAL_RENDER_ERROR] 日志 + 5 秒自动退出
• Kitty 协议 teardown 已在上游 cleanup chain 中于 instance.unmount() 之后执行

fork 的 gemini.tsx 内联了交互式 UI 设置，而上游委托给 startInteractiveUI.tsx——所以 PR 对 gemini.tsx 的修改无法映射到上游架构。

真正新的、上游还没有的改进：

1. uncaughtException handler 中同步写 debug log
2. 写 stderr 前先退出 alternate screen（?1049l）
3. consumeLastRenderError() 在 unmount 后回显渲染错误
4. SIGHUP handler
5. 移除 kittyProtocolDetector.ts 中与主信号处理器竞争的 SIGTERM/SIGINT handler

这些值得合入上游——但应该作为一个聚焦的 PR，基于当前 main rebase，修改 cli.ts 和 startInteractiveUI.tsx 而非 fork 的 gemini.tsx。

规模： 触及 253 个核心模块生产文件，绝大部分是 fork 分叉。

风险： 匹配 22 条高风险路径（均来自 fork 分叉）。

CI： 无构建/测试/lint 检查运行。

建议关闭此 PR，基于当前 main 重新提交一个只包含上述五项增量改进的聚焦 PR。

— Qwen Code · qwen3.8-max-preview

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

[qwen-code-ci-bot]

Code review

Independent proposal: given the problem (silent VP-mode exits, no error trace), I'd make five small changes to upstream's existing code: (1) add a sync fs.appendFileSync debug-log write to the existing uncaughtException handler in cli.ts, (2) have that handler emit ?1049l + ?25h before writing to stderr so the error lands on the main screen, (3) add consumeLastRenderError() to the existing ErrorBoundary.tsx and echo it in startInteractiveUI.tsx's cleanup chain, (4) add SIGHUP to the signal handlers, (5) remove the SIGTERM/SIGINT listeners from kittyProtocolDetector.ts. That's roughly five files, ~100 lines.

Comparison with the PR: the PR's fix logic matches this proposal closely — the setupUncaughtExceptionHandler, the alternate-screen exit before stderr, the consumeLastRenderError pattern, the SIGHUP addition, and the kitty signal-handler removal are all the right ideas. But they're implemented in the fork's gemini.tsx (which inlines the interactive UI setup) rather than upstream's cli.ts + startInteractiveUI.tsx, and they're buried in 1,149 files of fork divergence.

Findings on the fix code itself:

• ErrorBoundary.tsx would regress upstream's version. The PR's file is a near-copy of upstream's existing ErrorBoundary.tsx but drops the sanitizeTerminalText() call on error.message in the default fallback. Upstream added that to prevent terminal escape injection through crafted error messages. Merging this file as-is would silently remove that protection. The genuinely new part — consumeLastRenderError() + the module-level lastRenderError store — is clean and could be added to upstream's existing file in a few lines.

• setupUncaughtExceptionHandler in gemini.tsx is well-structured: sync write (correct — async would be abandoned by process.exit), alternate-screen exit before stderr, best-effort try/catch around both. But upstream's uncaughtException handler lives in cli.ts and also handles PTY-race suppression (isExpectedPtyRaceError). A focused PR would extend the existing handler rather than adding a parallel one in a different file.

• kittyProtocolDetector.ts change is the most directly upstream-applicable diff: removing the SIGTERM/SIGINT handlers that race with installInteractiveSignalHandlers(). The process.on('exit', disableProtocol) fallback is correctly kept. This one could land as-is.

• ErrorBoundary.test.tsx — 7 well-structured tests (healthy render, default/custom fallback, onError, reset recovery, non-Error normalization, consumeLastRenderError). These test the PR's ErrorBoundary variant; a focused PR would add the consumeLastRenderError test to upstream's existing test suite.

• The debugLogger.error(errorMessage) addition to setupUnhandledRejectionHandler is a good catch — ensures the debug log always records the rejection even when no UI listener is active. This is a one-line change that applies cleanly to upstream.

The remaining ~1,145 files are fork divergence (DataWorks features, .aoneci/ CI, .fork/ patches, branding, channel packages, core refactors) that I have not reviewed in detail — they are unrelated to the stated fix and would need separate, focused PRs if any of them are intended for upstream.

Testing

Check	Conclusion
precheck-pr / precheck	✅ success
label	✅ success
authorize	✅ success
triage	🔄 in progress
review-pr	⏭️ skipped / cancelled
verify	⏭️ skipped
tmux-testing	⏭️ skipped

No build, lint, typecheck, or unit-test CI has run on this commit — only bot orchestration checks. The precheck-pr gate passed, but the actual test suite has not been triggered (fork PRs may require workflow run approval). There is no CI evidence that this diff compiles against upstream main.

Sandboxed verification would settle the fix's behavioural claim: @qwen-code /verify — that the uncaughtException handler actually writes to the debug log and leaves the alternate screen before stderr output is not observable from the diff alone, and no CI has exercised it. This is a sponsored run (the author lacks write access); a maintainer's @qwen-code /verify comment approves the head it was written against, and the run carries a pre-execution risk screen plus a full workspace wipe. Read the resulting report with the same skepticism as the fork's own CI logs.

中文说明

独立方案： 针对 VP 模式静默退出问题，我会对上游现有代码做五处小改动：在 cli.ts 的 uncaughtException handler 中加同步 debug log 写入、写 stderr 前先退出 alternate screen、在现有 ErrorBoundary.tsx 中加 consumeLastRenderError()、添加 SIGHUP handler、移除 kittyProtocolDetector.ts 中的 SIGTERM/SIGINT 监听。大约五个文件、100 行代码。

与 PR 的对比： PR 的修复逻辑与这个方案高度吻合——思路都是对的。但实现在 fork 的 gemini.tsx 中而非上游的 cli.ts + startInteractiveUI.tsx，且被 1149 个文件的 fork 分叉所淹没。

修复代码本身的发现：

• PR 的 ErrorBoundary.tsx 会回退上游版本——丢失了 sanitizeTerminalText()（防止终端转义注入）。真正新的部分（consumeLastRenderError()）是干净的，可以几行代码加到上游现有文件中。
• setupUncaughtExceptionHandler 结构良好，但上游的 handler 在 cli.ts 中且处理了 PTY 竞争抑制。聚焦的 PR 应扩展现有 handler 而非在另一个文件中添加并行版本。
• kittyProtocolDetector.ts 的改动最直接适用于上游。
• 测试写得很好（7 个测试覆盖全面）。
• debugLogger.error() 添加到 setupUnhandledRejectionHandler 是一个好改动，一行代码即可适用于上游。

测试： 无构建/lint/类型检查/单元测试 CI 运行。无证据表明此 diff 能针对上游 main 编译。

— Qwen Code · qwen3.8-max-preview

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

[qwen-code-ci-bot]

Confidence: 2/5 — the investigation is thorough and the fix ideas are sound, but the PR as structured cannot merge: it's a 250-commit fork divergence that would overwrite upstream code with a less secure version and target architectural entry points that don't exist upstream.

Stepping back: the crash analysis here is genuinely good work. The stderr-to-alternate-screen silence mechanism, the sync-vs-async debug log insight, the kitty signal-handler race — these are real findings from real debugging, not theoretical hardening. The five incremental improvements I called out in Stage 1 are worth upstreaming.

But this PR is not the vehicle for that. Three blocking issues:

1. ErrorBoundary.tsx regresses upstream's security. The PR's version drops sanitizeTerminalText() from the error message render path. Upstream added that to prevent terminal escape injection through crafted error messages — a model or tool that throws Error('\x1b[...') could write arbitrary escape sequences to the user's terminal. Merging this file as-is silently removes that protection.

2. Architectural mismatch. The fork's gemini.tsx inlines the interactive UI setup; upstream delegates to startInteractiveUI.tsx and cli.ts. The PR's setupUncaughtExceptionHandler and ErrorBoundary wrapping are in the wrong file for upstream. A focused PR would extend the existing uncaughtException handler in cli.ts (which already handles PTY-race suppression) and add consumeLastRenderError() to the existing ErrorBoundary.tsx.

3. 1,149 files of fork divergence. .aoneci/ CI scripts, .fork/ patch infrastructure, DataWorks branding, channel packages, and extensive core refactors — none of which belong in a fix for silent VP-mode crashes. No CI has run to verify this diff compiles against upstream.

The path forward is straightforward: close this PR, rebase on current main, and submit a focused PR with the five incremental improvements. The kitty signal-handler removal (kittyProtocolDetector.ts) and the debugLogger.error() addition to setupUnhandledRejectionHandler are near-drop-in patches. The consumeLastRenderError pattern needs a small addition to upstream's existing ErrorBoundary.tsx. The uncaughtException handler improvements (sync debug log + alternate-screen exit) extend the existing handler in cli.ts.

Requesting changes — not because the ideas are wrong, but because the PR needs restructuring before it can be reviewed and merged meaningfully.

中文说明

信心：2/5 — 调查很深入，修复思路也很好，但 PR 的结构决定了它无法合入：这是一个 250 commit 的 fork 分叉，会用安全性更低的版本覆盖上游代码，并且针对上游不存在的架构入口。

三个阻塞问题：

1. ErrorBoundary.tsx 回退了上游的安全性——丢失了 sanitizeTerminalText()（防止终端转义注入）。
2. 架构不匹配——fork 的 gemini.tsx 内联了交互式 UI 设置，上游委托给 startInteractiveUI.tsx 和 cli.ts。
3. 1149 个文件的 fork 分叉——与 VP 模式崩溃修复无关。

建议路径： 关闭此 PR，基于当前 main rebase，提交一个聚焦的 PR，包含五项增量改进。kittyProtocolDetector.ts 的信号处理器移除和 setupUnhandledRejectionHandler 的 debugLogger.error() 添加几乎可以直接应用。consumeLastRenderError 需要对上游现有 ErrorBoundary.tsx 做小改动。uncaughtException handler 的改进（同步 debug log + alternate screen 退出）扩展 cli.ts 中的现有 handler。

请求修改——不是因为思路错误，而是 PR 需要重构才能被有意义地审查和合入。

— Qwen Code · qwen3.8-max-preview

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

[qwen-code-ci-bot]

Needs restructuring — see my notes above. The fix ideas are solid, but the PR is a 250-commit fork divergence that would overwrite upstream's ErrorBoundary (losing sanitizeTerminalText) and target the wrong architectural entry points. A focused PR on current main with the five incremental improvements would be very welcome. 🙏