Server has no process-wide SIGPIPE handling — a broken-pipe stderr/stdout SIGKILLs it (27 write sites; #303's staleness warning is the earliest trigger)

[kiki830621]

Problem

The server installs no SIGPIPE handler. Any write to a broken pipe (write end open, read end gone) is killed by the kernel's default SIGPIPE disposition before write() returns to Swift — so no try? / do-catch can intercept it. There are 27 FileHandle.standardError.write sites across Sources/ (Server.swift, MailController.swift, ExportEmailsMarkdown.swift) and grep finds no signal() / SIG_IGN. Every one of them is a potential SIGPIPE kill if the host closes the read end of the server's stderr (or stdout) while the server keeps running.

Verified on the shipped binary (not a proxy)

Launched the real CheAppleMailMCP with fd 2 = the write end of a reader-closed pipe:

Scenario	Result
version drift present (#303 emitDiagnostic fires at startup)	server killed by signal 13 (SIGPIPE)
no drift / no sidecar (emitDiagnostic silent)	server survives
standalone probe, default disposition	exit 141 (128+SIGPIPE)
standalone probe, signal(SIGPIPE, SIG_IGN) first	exit 0, survives

So #303's staleness warning is not a new crash class — it is the earliest stderr write on the startup path, which makes an already-fatal fd-2 state fatal at startup (on the drift path) rather than at the first log write during tool use. The other 26 writers would kill the same fd-2 state later regardless.

Surfaced by the round-5 verify of PR #307; the CHANGELOG + emitDiagnostic doc comment there now state this boundary precisely rather than claiming blanket "crash-proof".

Reachability

Narrow for a normally-launched stdio MCP server: the parent (Claude Desktop / launcher) normally holds the read end of the server's stderr for logging, so fd 2 does not become a broken pipe on its own. It requires the host to close its stderr reader while keeping the server alive. But it is a real state, and the failure is a hard SIGKILL, not a graceful degrade.

The fix is not a one-liner — hence a separate issue

The obvious fix is a process-wide signal(SIGPIPE, SIG_IGN) at startup, which converts the kill into an EPIPE errno the throwing write already swallows — fixing all 27 sites at once. But SIG_IGN without corresponding EPIPE handling on the stdout path can turn a clean "client disconnected → exit" into a spin: today a stdout write after the client closes gets SIGPIPE and the process dies (crude but terminal); with SIG_IGN it returns EPIPE, and the server must then detect that (or stdin-EOF) and exit cleanly. So this needs the MCP stdio server's shutdown path validated before flipping the disposition — deliberately out of #303's scope.

Suggested approach

1. Confirm the server exits cleanly on stdin EOF (the normal client-disconnect signal), independent of stdout SIGPIPE.
2. Add signal(SIGPIPE, SIG_IGN) once at process startup.
3. Verify a broken-pipe stdout no longer spins (relies on step 1).
4. A regression test spawning the real binary with a broken-pipe fd 2 (the harness above) asserting it survives.

Related

• Same failure mode bug: 草稿建立目前卡住 — 全路徑 re-test（create_draft clean/legacy・update_draft・reply/forward save_as_draft） #301 already handled locally on the osascript subprocess stdin path (throwing write(contentsOf:)), which works there only because that write is not to the process's own fd 1/2 default-disposition path.
• A stale long-lived MCP server can still hang-to-disconnect: #297/#301 fix the server, but the session-boundary-only staleness kill can miss an old in-memory image #303 / PR Surface stale-binary staleness + fix hardcoded server version (Refs #303) #307 introduced emitDiagnostic as the earliest trigger and documented the boundary.

Current Status

• Phase: diagnosed
• Updated: 2026-08-01 (idd-all batch)
• Diagnosis: see the ## Diagnosis comment below (root cause, strategy checklist, conflict class, complexity)

[kiki830621]

Diagnosis

Type

bug（hardening — pre-existing whole-server property）

Root Cause / Analysis

Server 從未設定 SIGPIPE disposition（grep 全 Sources 無 signal(/SIG_IGN），kernel 預設對「寫入 broken pipe」直接終止 process——在 write() 把控制權交回 Swift 之前，所以任何 try?/do-catch 都攔不到。main 上有 26 個 FileHandle.standardError.write 呼叫點（PR #307 會加第 27 個），每一個都是潛在 kill point。

已在真 binary 上實證（#307 round-5 verify）：fd 2 = reader 已關的 pipe 時，有 staleness drift（emitDiagnostic 於啟動觸發）→ server 被 signal 13 殺掉；無 drift → 存活。獨立 probe：預設 disposition exit 141；signal(SIGPIPE, SIG_IGN) 後 exit 0。

可達性誠實評估：正常 stdio MCP 佈署下 parent（Claude Desktop / Claude Code）持有 stderr read 端收 log，fd 2 不會自己變 broken pipe——需要 host 關掉 reader 卻留著 server。窄，但失敗形態是 hard kill 非 graceful degrade。

Impact

• 影響的檔案：Sources/CheAppleMailMCP/main.swift（加 disposition）＋ 新測試
• 影響的使用者流程：stderr/stdout reader 消失的 host 環境下，一次診斷寫入即殺整個 server（53 tools 全下線）

Strategy

修法不是一行 SIG_IGN——SIG_IGN 之後，client 斷線時對 stdout 的寫入從「SIGPIPE 死掉（粗暴但會終止）」變成「回 EPIPE errno」，若 stdio transport 不因此收斂，server 會從「斷線即死」變「斷線後空轉」。所以順序是：

• 先驗證 stdin-EOF 是正常的 client-disconnect 收斂路徑（MCP swift-sdk stdio transport：讀到 EOF 是否結束 waitUntilCompleted）——用真 binary 實測（關 stdin、量 exit）
• main.swift 進入點加 signal(SIGPIPE, SIG_IGN)（在任何 transport 啟動前）
• 實測 broken-pipe stdout + 已斷 stdin：確認 server 乾淨退出、不空轉
• 回歸測試：spawn 真 binary、fd 2 = broken pipe + 製造 stderr 寫入 → 斷言存活（鏡射 Surface stale-binary staleness + fix hardcoded server version (Refs #303) #307 round-5 的 driver 手法；同時鎖 stdin-EOF 收斂）

Conflict Class

A_parallel_safe — batch 內無其他 issue 動 main.swift。與未 merge 的 PR #307 共享 main.swift（#307 在同一個 switch 加 .version case）：不同區域（本 fix 在 switch 之前的頂部）、textual adjacency 低，後 merge 者順手解。

Complexity

Plan — 改的是 process 級 signal disposition，風險點在 shutdown 語意（EPIPE-spin），需要先做收斂驗證再動手；decision-heavy 而非 code-heavy。

Risks

• SIG_IGN 後斷線空轉（上述——被 strategy 第 1/3 步直接檢驗）
• 測試依賴 spawn 真 binary，需注意 suite 時長（Surface stale-binary staleness + fix hardcoded server version (Refs #303) #307 的 runBriefly 模式已證明可控 ~6s/case）

Residue

「host 應不應該在 UI 呈現 restart 提示」（#320 只管不死，不管可見性）—— 已由 #312/#303 的 scope 文件另行處理，非本 issue 範圍。

[kiki830621]

Closing Summary

Root cause: the process never set a SIGPIPE disposition. The kernel's default kills the process on a broken-pipe write before write() returns to Swift — unreachable by any try?/do-catch — and the server has ~26 stderr write sites plus the stdout stdio transport. Verified on the real binary: delivered SIGPIPE → death by signal 13, 2/2.

Solution (PR #328, squash-merged as 451149b): signal(SIGPIPE, SIG_IGN) in main.swift before any transport starts; broken-pipe writes become EPIPE errnos the throwing write sites already swallow. Sequenced per the diagnosis to avoid trading death-on-disconnect for spin-on-disconnect: stdin-EOF was verified as the governing clean-shutdown path before the change (exits rc=0 independent of stdout state), then the fix, then broken-pipe stdout + stdin-EOF verified live to still exit cleanly.

Verification: SigpipeDispositionTests pins the disposition by delivering SIGPIPE to the real spawned binary — deterministic and load-independent (pre-fix dies 2/2, post-fix survives 2/2). A bounded exit-after-EOF assertion was deliberately NOT added: interleaved A/B showed 4s→>40s latency variance on the unmodified binary (pre-existing, filed as #329) — an initial non-interleaved measurement wrongly implicated this fix before interleaving dissolved it into load noise (recorded for measurement honesty). 1069 pre-merge; 1090/0 on integrated main.

Residue: #329 (shutdown-latency variance, suspected startup-sync interaction) and the per-site EPIPE-behavior audit of the remaining non-throwing write call sites — both out of this issue's disposition-level scope.