Qoder crash bug without being fixed after multiple versions

# Qoder Bug Feedback

## 问题描述

Qoder 桌面版(com.qoder.app,非 IDE)0.3.4 在 macOS 上存在主进程静默退出的缺陷:凡是经 Dock 点击、安装器或更新后自动拉起(即 LaunchServices 链路)启动的实例,在正常使用 agent 对话、尤其是模型正在流式输出回复时,主进程会在 2 到 6 分钟内无声消失,没有任何弹窗与错误提示,用户侧表现为"闪退"。四组对照实验(同一台机器、同一恢复会话、相同负载)证实该问题与 LaunchServices 启动方式强绑定:Dock 启动必现,而用终端直接执行应用二进制则完全稳定,与 shell 环境变量、ELECTRON_ENABLE_LOGGING 开关、用户数据、SDK worker 均无关。更严重的是,该版本的 Crashpad 崩溃上报从未初始化(com.qoder.app.stable/Crashpad/ 下只有 settings.dat),崩溃遥测完全失效——受影响用户的闪退在你们后台是零痕迹,"收不到崩溃报告"本身就是这个 bug 的一部分。

## 复现步骤

1. 在 macOS 上从 Dock 点击启动 Qoder;

2. 打开任一已有会话(或新建对话),发起 agent 任务并连续多轮对话;

3. 约 2~6 分钟内、通常恰逢模型流式回复输出时,整个窗口无声消失;

4. 对照组:终端执行 `/Applications/Qoder.app/Contents/MacOS/Qoder` 后重复完全相同的操作,不再复现——三次对照分别稳定运行 10 分钟 6 轮对话、4 分钟、4 分半 4 轮对话(含多 agent 任务)。

## 期望行为

应用应持续稳定运行;即使内部确有致命错误,主进程也应走完整的 Electron 生命周期(before-quit / will-quit / shutdown 并写入日志),生成 Crashpad 崩溃报告并上报遥测,同时向用户展示错误提示——而不是无声消失。

## 实际行为

主进程在模型流式回复期间直接调用 exit() 退出,完全跳过应用自身的关机流程。两次实测的死亡签名(2026-09-23 10:37:41.249 与 11:05:41.249,+0800)逐字段一致:应用 main.log 戛然而止,连 before-quit 日志都没有,全部 shutdown participant 记录缺失;而 macOS 统一日志中出现的是正常退出序列——CoreAnalytics 的 “Entering exit handler / Queueing exit procedure … Any further messages sent will be discarded / Exiting exit handler”——说明这是 process.exit()/app.exit() 级别的强退,既非段错误也非 SIGKILL。全系统找不到任何 .ips 崩溃报告,也没有 JetsamEvent 与内核 kill 记录(OOM、安全软件、Gatekeeper 均已逐一排除);loginwindow 记录了 applicationDeath,联盟内的子进程(utility node、chrome_crashpad_handler、atc 守护等)在约 13 秒内集体消亡。四组对照实验(A:终端执行+完整 shell 环境稳定;B:Dock 启动 2.5 分钟即崩;C:终端执行、无日志开关稳定;D:终端执行+launchd 极简环境稳定)将唯一变量收敛到 LaunchServices 启动上下文本身(父进程、LS/FrontBoard 注册、stdio)。

## 截图或录屏

静默退出无法用静态截图表达,建议用 ⌘⇧5 录屏记录"Dock 启动 → 正常对话 → 模型流式回复中窗口消失"的全程(约 3 分钟),并可加录一段终端启动的对照组。决定性的文字证据为上文引述的 unified log 序列;应用端完整会话日志位于 `~/Library/Application Support/com.qoder.app.stable/logs//main.log`,9 月 21 日以来的多个会话保留了多次死亡现场,需要时可以打包提供。

## 操作系统

macOS 27.0(Build 26A428),Apple Silicon arm64e,Mac16,7,24 GB 内存。

## 当前版本

Qoder.app 0.3.4(stable 渠道,Electron 43.1.1;更新服务器当前返回的 stable 最新版即为 0.3.4,无更高版本可升级)。以菜单 About Qoder 中 Copy 的版本串为准。

—

## Issue Description

The macOS desktop app Qoder.app (com.qoder.app, not the IDE) v0.3.4 silently self-exits: any instance launched through the Dock, the installer, or the auto-updater relaunch — collectively the LaunchServices pathway — quits without warning within 2–6 minutes during normal agent chat usage, typically while a model response is streaming. There is no dialog, no crash report, and nothing in the app’s own log; users simply experience a random crash-to-desktop. Four controlled experiments (same machine, same restored chat session, same workload) tie the defect specifically to the LaunchServices launch path: Dock launches always crash, while executing the app binary directly from a terminal is 100% stable — irrespective of shell environment variables, the ELECTRON_ENABLE_LOGGING switch, user data, or SDK worker state. Worse, Crashpad is never initialized in this build (com.qoder.app.stable/Crashpad/ contains only settings.dat), so crash telemetry is dead: crashes of affected users leave zero trace on your backend. Receiving no crash reports at all is itself part of this bug.

## Steps to Reproduce

1. Launch Qoder from the Dock on macOS.

2. Open any existing chat session (or start a new one) and run agent tasks across several consecutive turns.

3. Within roughly 2–6 minutes — usually right while a model response is streaming — the entire window disappears without any prompt.

4. Control: run `/Applications/Qoder.app/Contents/MacOS/Qoder` from a terminal and repeat exactly the same usage; the crash does not reproduce. Three control runs stayed stable for 10 minutes/6 turns, 4 minutes, and 4.5 minutes/4 turns (including multi-agent tasks).

## Expected Behavior

The app should keep running. Even when a genuine fatal error occurs internally, the main process should go through the complete Electron lifecycle (before-quit / will-quit / shutdown, with logging), produce a Crashpad dump, report telemetry, and surface an error to the user — not vanish silently.

## Actual Behavior

The main process calls exit() mid-stream, bypassing the application’s entire shutdown flow. Two measured death signatures (2026-09-23 10:37:41.249 and 11:05:41.249, +0800) match field-for-field: the app’s main.log stops dead with not even a before-quit entry and none of the shutdown participant records; meanwhile the unified log shows an orderly exit sequence — CoreAnalytics’ “Entering exit handler / Queueing exit procedure … Any further messages sent will be discarded / Exiting exit handler” — indicating a process.exit()/app.exit()-grade forced exit rather than a segfault or SIGKILL. There are no .ips crash reports anywhere on the system, no JetsamEvent, and no kernel kill records (OOM, security software, and Gatekeeper were each ruled out with direct evidence); loginwindow logs applicationDeath, and the coalition’s child processes (utility node workers, chrome_crashpad_handler, atc daemons) die collectively within ~13 seconds. Four controlled runs converge on a single variable: A (terminal exec + full shell env) stable; B (Dock) crashes in 2.5 minutes; C (terminal exec, no logging flag) stable; D (terminal exec + minimal launchd env) stable — the determinant is the LaunchServices launch context itself (parent process, LS/FrontBoard registration, stdio).

## Screenshots / Screen Recordings

A silent exit cannot be captured in a static screenshot; a screen recording (⌘⇧5) of “launch from Dock → normal chat → the window disappears mid-stream” (~3 minutes) is recommended, ideally paired with a terminal-launch control run. The decisive textual evidence is the unified log sequence quoted above; full app-side session logs live at `~/Library/Application Support/com.qoder.app.stable/logs//main.log`, with several death scenes preserved in sessions since Sep 21 — they can be packaged on request.

## Operating System

macOS 27.0 (Build 26A428), Apple Silicon arm64e, Mac16,7, 24 GB RAM.

## Current Qoder Version

Qoder.app 0.3.4 (stable channel, Electron 43.1.1; the update server currently reports 0.3.4 as the latest stable, so no newer build is available to upgrade to). Please treat the version string copied from Menu → About Qoder as authoritative.