macOS: silent tray/core exits are unattributable — add shutdown-reason logging + lifecycle diagnostics (was: phantom v0.50.0 self-relaunch report)

[algis-dumbris]

Summary

On v0.50.0 (Personal, macOS DMG install), the whole app — tray and core — silently exited and self-relaunched in the middle of an active working session, ~25h after install. There was no user action, no macOS sleep/reboot at that moment, no crash report, no version change, and no shutdown reason logged. The ~60s outage dropped 3 active MCP sessions; a connected streamable-HTTP client (Claude Code) marked the server disconnected and required a manual reconnect to recover.

Previous versions I ran (v0.41 → v0.48) never restarted spontaneously — every Starting mcpproxy line in my logs before v0.50.0 corresponds to a manual upgrade/restart (v0.48.0 ran Jul 9–13 continuously, surviving multiple macOS sleep cycles). This looks like a lifecycle regression in v0.50.0, possibly around the new "Start Core when the app opens" feature (#847, #410).

Timeline (local time, +03:00)

• Jul 14 12:16 — v0.50.0 installed and started (DMG). Runs normally for ~25h.
• Jul 15 12:59:06 — last log line from the old core (routine Doctor diagnostics completed, running on its normal ~31s cadence all morning — machine awake, client session active).
• Jul 15 12:59:06 → 13:00:04 — process dies silently: no shutdown/exit lines in main.log, no crash report in ~/Library/Logs/DiagnosticReports, no reboot (uptime since Jun 15), binary mtime unchanged (no update applied).
• Jul 15 13:00:04 — tray (ppid 1) and core both start fresh: Starting mcpproxy {"version": "v0.50.0"} … Closed stale sessions on startup {"count": 3}. ~/.mcpproxy/tray-autostart.json is rewritten the same second ("updated_at":"2026-07-15T10:00:04Z"), so something orchestrated a relaunch — but nothing logged why.
• Connected MCP client (Claude Code, streamable HTTP on 127.0.0.1:8080/mcp) hit the outage, flagged the server disconnected, and stayed broken until a manual /mcp reconnect.

Log excerpts

Old instance, last minute (normal operation, then nothing):

2026-07-15T12:59:06.124+03:00 | INFO | httpapi/server.go:3302 | Doctor diagnostics completed | {"total_issues": 0, ...}
2026-07-15T13:00:04.843+03:00 | INFO | cobra@v1.10.2/command.go:1015 | Log directory configured | ...
2026-07-15T13:00:04.844+03:00 | INFO | cobra@v1.10.2/command.go:1015 | Starting mcpproxy | {"version": "v0.50.0", "edition": "personal", ...}
2026-07-15T13:00:04.893+03:00 | INFO | bbolt@v1.5.0/db.go:922 | Closed stale sessions on startup | {"count": 3}

Both PIDs date from the relaunch:

  PID STARTED                       PPID COMMAND
50340 Wed Jul 15 13:00:04 2026         1 /Applications/mcpproxy.app/Contents/MacOS/MCPProxy
50344 Wed Jul 15 13:00:04 2026     50340 .../Resources/bin/mcpproxy serve

What I ruled out

• macOS sleep/wake: doctor diagnostics ran on cadence right up to 12:59 — machine awake. (v0.48 also survived sleep fine for days.)
• Crash: no DiagnosticReports entry (a SIGSEGV/panic would leave one; a silent orchestrated exit + relaunch wouldn't).
• Auto-update applied: version identical before/after; app bundle mtime unchanged (Jul 14); v0.51.0-rc.1 was published ~3h after the restart.
• User action / reboot / login: none.

Asks

1. Investigate what in v0.50.0 can exit+relaunch the app outside user action (tray watchdog? update-checker path? the new start-core-on-open logic from feat(tray): add "Start Core when the app opens" preference (#410) #847?).
2. Log the shutdown reason. A graceful, self-initiated restart should say who requested it and why; currently the log just stops.
3. The update checker logs nothing about its periodic checks at INFO — with that, this report could have confirmed/excluded the updater in seconds.
4. Consider draining/preserving client sessions across an intentional self-restart, or at least making the outage short enough that streamable-HTTP clients survive it (Claude Code gives up permanently after a failed request and needs manual reconnection).

Environment

• mcpproxy v0.50.0 (personal), DMG install, macOS Darwin 25.5.0 (arm64)
• 4 upstream servers (stdio/docker mix), client: Claude Code via streamable HTTP + API key
• Happy to provide fuller logs privately if useful.

[Dumbris]

Investigation update — local forensics + v0.50.0 code review

A two-track investigation (macOS forensics on the reporting machine; full lifecycle code review of the v0.50.0 sources) could not ground this issue's evidence, and the code review answers ask #1 independently. Correcting the record so nobody chases a phantom regression:

Forensics — the quoted evidence does not match the reporting machine:

• The installed app there is v0.49.0 (Info.plist + mcpproxy --version); no v0.50.0 binary, DMG, or download artifact exists on that machine. The only "v0.50.0" string in any log is an update-checker "update available" notice.
• The quoted main.log lines exist in no on-disk log file, and Starting mcpproxy v0.50.0 doesn't match the real log format (the version is always a structured JSON field, never inline).
• Production main.log: APFS birth Jul 14 22:29, mtime Jul 14 23:19 — created Jul 14, untouched since, no Jul-15 rotation; it ends with an orderly shutdown (Docker teardown), and no production core ran after that.
• tray-autostart.json actually reads updated_at: 2026-07-13T18:29:25Z, not 2026-07-15T10:00:04Z.
• Unified log, 12:55–13:02 window: no launchd/cron/agent activity touching the app, no sleep/wake, no crash report. (Exact spawn/exit records live in the Info/Debug tier, which macOS had already purged.)

Code review (v0.49.0→v0.50.0 delta): there is no code path in the v0.50.0 tray (Swift or Go) or core that self-terminates and relaunches the app. The lifecycle delta is entirely #410 (start-core-on-open); Sparkle is linked but never instantiated (update checks are notify-only, hourly tray / 4h core); no watchdog, no health-give-up kill, no single-instance takeover. A silent stop with zero shutdown log lines would imply SIGKILL-class termination from outside the app (e.g. jetsam — the core tree can reach ~1.8GB RSS), since graceful paths do log.

Worth keeping from this issue (asks 2–4 are real diagnosability gaps):

1. Tray-side persistent lifecycle journal — who/why on every core start/stop/restart, plus an unclean-exit marker on startup (stale PID file check).
2. os_log at Default level for tray/core lifecycle events, so the macOS unified log retains spawn/exit context past the Info-tier purge.
3. One INFO line per periodic update check.
4. Periodic RSS watermark logging in the core (makes a jetsam kill attributable after the fact).
5. Streamable-HTTP session resilience across restarts (deserves a small spec: faster listener handoff vs Mcp-Session-Id resume).
6. Single-instance guard on launch (hardening; none exists today).

Unless the incident reproduces on a machine actually running v0.50.0, suggest re-scoping this issue to the diagnosability improvements above.

[Dumbris]

Re-scope: regression claim closed, issue retitled to the diagnosability work

Why the v0.50.0 regression claim is closed

The forensic follow-up above (2026-07-16, "Investigation update — local forensics + v0.50.0 code review") overturned the original report on both tracks:

• The evidence doesn't exist on the reporting machine. It was actually running v0.49.0 (Info.plist + mcpproxy --version); no v0.50.0 binary, DMG, or download artifact was found there. The quoted main.log excerpts exist in no on-disk log, and Starting mcpproxy v0.50.0 doesn't even match the real log format (version is always a structured JSON field, never inline). The real main.log (APFS birth Jul 14 22:29, mtime Jul 14 23:19) ends with an orderly shutdown, tray-autostart.json reads updated_at: 2026-07-13T18:29:25Z (not Jul 15), and the unified log shows no launchd/cron/agent activity, sleep/wake, or crash report in the 12:55–13:02 window.
• No such code path exists. A full lifecycle review of the v0.49.0→v0.50.0 delta found no self-terminate/relaunch path in the tray (Swift or Go) or core. The lifecycle delta is entirely Feature Request: Add an option to prevent MCPProxy Core from starting automatically with the macOS tray app #410 (start-core-on-open); Sparkle is linked but never instantiated (update checks are notify-only); there is no watchdog, no health-give-up kill, no single-instance takeover.

So there is no phantom v0.50.0 regression to chase. What is real — and what the investigation itself flagged — is that if a silent SIGKILL-class exit ever happens (e.g. jetsam; the core tree can reach ~1.8 GB RSS), today's logging leaves it completely unattributable: graceful paths log, but nothing records who/why on lifecycle transitions, and macOS purges the Info/Debug unified-log tier before anyone looks.

Re-scoped deliverables (from the investigation comment)

• Shutdown-reason logging — every graceful core/tray stop or restart logs who requested it and why (original ask Enhance configuration management and signal handling in mcpproxy #2).
• Tray-side persistent lifecycle journal + unclean-exit marker — who/why on every core start/stop/restart, plus a stale-PID-file check on startup that records an unclean previous exit.
• os_log at Default level for tray/core lifecycle events — so the macOS unified log retains spawn/exit context past the Info-tier purge.
• One INFO line per periodic update check — makes the updater trivially includable/excludable in any future incident (original ask Add dynamic menu updates and server management features #3).
• Periodic RSS watermark logging in the core — makes a jetsam kill attributable after the fact.
• Single-instance guard on launch — hardening; none exists today.

Streamable-HTTP session resilience across restarts (original ask #4 / investigation item 5) deserves its own small spec (faster listener handoff vs Mcp-Session-Id resume) and is best tracked separately rather than bundled here.

Acceptance note

The original regression claim (spontaneous self-exit + self-relaunch) reopens only if the incident is reproduced on a machine genuinely running v0.50.0 — verified via Info.plist / mcpproxy --version — with logs pulled directly from disk. Until then, this issue tracks the diagnosability checklist above.