当用户发送消息后未等到回复便直接关闭聊天窗口（无论是终端窗口还是浏览器标签页），Claude Code 的内部处理流程实际上相当严谨精妙。下面我们逐一拆解各环节，看看每一步都完成了什么任务。
1. 信号触发
不同操作系统下，关闭窗口时产生的终止信号有所差异，但共同目标都是通知进程“立即清理并退出”。
| 平台 | 信号类型 | 检测机制 |
|---|---|---|
| Linux / WSL | SIGHUP | 终端关闭时由内核自动发送 |
| macOS | TTY 吊销 | 无 SIGHUP 支持，改用 30 秒轮询检查 process.stdout.writable |
| Windows | SIGTERM | 窗口关闭事件触发 |
| 用户主动 Ctrl+C | SIGINT | 键盘中断指令 |
信号的统一处理入口位于 gracefulShutdown.ts 的 setupGracefulShutdown() 函数中，在 entrypoints/init.ts:87 处注册。换言之，项目启动后就已经挂接了对应的钩子，随时准备好响应这些“非正常退出”事件。
2. 取消正在进行的 API 请求
一旦信号被捕获，整个关闭流程便立即启动：
SIGHUP/SIGTERM/SIGINT→ gracefulShutdown()→ cleanupTerminalModes() ← 恢复终端原始模式→ printResumeHint()← 输出 "Resume with: claude --resume "→ 此时 AbortController 已被触发:queryLoop 中的 signal.aborted == true→ anthropic.beta.messages.create({...params, stream: true}, { signal })中的 signal 被触发 → SDK 抛出 APIUserAbortError→ stream 终止，不再接收后续数据 关键链路非常清晰：用户发送消息时，onQueryImpl 会创建一个 AbortController（代码位于 REPL.tsx:4010），该控制器携带的 signal 被传入 queryModel()，随后传递给 Anthropic SDK 的 messages.create() 作为终止信号。关闭窗口后，controller 一发出 abort，SDK 立即中断 HTTP 流，从而避免资源浪费和不必要的数据处理。
3. 刷新会话持久化
取消请求只是第一步，更重要的是将已经发生的交互数据安全保存。
// gracefulShutdown.ts:445
await runCleanupFunctions()
→ Project.flush() ← 将内存 100ms 队列中的待写入消息刷入 JSONL 文件
→ Project.reAppendSessionMetadata() ← 重新将会话元数据追加写入到文件尾部已经发出的用户消息，以及已收到的那部分助手回复（如果有），都会立刻写入 JSONL 文件。若一条回复都未来得及接收，则仅记录用户消息——但至少用户发送的内容不会丢失。
4. 执行 SessionEnd hooks
// gracefulShutdown.ts:473
await executeSessionEndHooks(reason, { signal, timeoutMs })此处为用户自定义的 SessionEnd 钩子提供了执行机会，默认超时时间为 1.5 秒。假如配置了清理任务或其他收尾动作，会在此阶段执行完毕。
5. failsafe 兜底
// gracefulShutdown.ts:417
failsafeTimer = setTimeout(() => {
cleanupTerminalModes();
printResumeHint();
forceExit(code);
}, Math.max(5000, sessionEndTimeoutMs + 3500),)万一上述异步清理过程发生阻塞（例如钩子卡死），兜底计时器将起到保障作用。默认 5 秒（或者钩子超时时间 + 3.5 秒）后强制退出进程。必须有一个底线，否则进程将永远无法结束。
6. 退出后
- 终端输出提示
Resume this session with: claude --resume - 进程退出码为 129 (SIGHUP) / 143 (SIGTERM) / 0 (Ctrl+C)
- JSONL 文件保留在磁盘上，以供后续恢复会话使用
- 消息已部分写入 JSONL — 恢复后会展示已发送的消息，但回复可能不完整或缺失（取决于流式输出当时的位置）
退出并不是终点，而是为下次恢复留下了窗口。
关键要点
| 问题 | 答案 |
|---|---|
| 已发送的消息会丢失吗？ | 不会 — runCleanupFunctions() 会将内存队列刷新到 JSONL 文件 |
| 已收到的部分回复会被保存吗？ | 会 — 已输出的 assistant message 片段已成功写入 |
| API 会继续处理吗？ | 不会 — abort signal 触发后，API 虽可能收到 TCP 断开但仍会处理，然而结果会被丢弃 |
| 能否恢复会话继续对话？ | 可以 — 使用 claude --resume 重新加载 JSONL 文件，恢复上下文后继续交流 |
整个流程从信号到来，到最终强制退出，层次分明、逻辑严谨。既保证了数据不丢失，又避免了 API 资源无限浪费，还给用户留下了便捷的恢复路径。这种设计，既可靠又人性化。
