MCP server silently killed+respawned mid-session (SIGINT/SIGTERM), transient sessionId leaks into task path

Summary

An MCP server (local-memory, stdio transport) was deliberately killed by Claude Code's own connection-management logic (SIGINT → SIGTERM) mid-session, then respawned 3 times within ~6 minutes. During the respawns, the debug log's sessionId field was inconsistent within a single connection's own log lines, and a background Agent task's output-file path picked up one of these transient session ids instead of the real session id — producing a confusing "session ID changed mid-conversation" symptom with no accompanying error.

Version: 2.1.228, darwin-arm64, CLI entrypoint (not SDK).

What happened (evidence, not inference)

1. Session e3c689db-...'s own local-memory MCP log

(~/Library/Caches/claude-cli-nodejs/<cwd-slug>/mcp-logs-local-memory/)
shows the client killing its own child process:
``
07:52:51.226Z "Sending SIGINT to MCP server process"
07:52:51.326Z "SIGINT failed, sending SIGTERM to MCP server process"
07:52:51.330Z "MCP server process exited cleanly"
``

1. It respawned 3 times in the next ~6 minutes (07:53:00, 07:57:39, 07:58:57), each a fresh Starting connection → Successfully connected cycle (~400-700ms).
2. Each respawn's log file recorded a different sessionId field value at connect time — none of them matching e3c689db (the actual, correct session). One respawn's log even logs two different sessionId values across its own 4 lines (connect-time lines say one id, a later "Channel notifications skipped" line 21s afterward says a different, correct one).
3. A background Agent dispatch's output-file path in the main session transcript used one of these transient session ids as its path prefix (/private/tmp/claude-501/<cwd-slug>/<transient-id>/tasks/...), instead of the real session's id — this is the artifact that made it look, from inside the conversation, like the whole session/process had silently restarted.
4. Separately, that same background agent came back with status: stopped and the message "No completion record was found for background agent ... from the previous session. It may have been stopped, or it may have been running when the previous Claude Code process exited" — worth noting this message's own wording assumes/implies a full process exit, which doesn't match what the MCP log shows (only the MCP child was killed, not the main claude process — no crash reporter entry, no OOM/jetsam log line, CLI stayed on a stable already-updated version throughout).

What this is NOT (ruled out)

• Not an OS-level crash: no ~/Library/Logs/DiagnosticReports/*claude* entry, no crash/OOM/jetsam line in log show for the incident window.
• Not a CLI auto-update mid-session: the last update (2.1.227→2.1.228) completed >30 min before the session started; the session ran entirely on a stable 2.1.228.
• Not an issue with the MCP server itself (local-memory): its own log never shows it erroring or exiting on its own — every relevant log line is the client announcing what it's doing to the server.

Ask

1. Is the MCP connection-recycling/health-check logic (uptime cap / consecutive-error threshold / session-expiry detection — inferred from adjacent string literals in the binary: "<server> connection dropped after <N>s uptime", "MCP session expired (server no longer recognizes session ID), triggering reconnection") expected to fire this often (3x in 6 min) against a healthy, responsive local stdio server?
2. Is it expected/intended that the sessionId tagged in mcp-logs-<server>/*.jsonl can differ from the actual owning session's id during a respawn, and that this transient/incorrect id can leak into a background task's output-file path? This is the part that produces the "did my session just silently restart?" scare with zero accompanying error surfaced to the user.

Happy to share the exact log excerpts/timestamps referenced above if useful — trimmed here for length.