Server exits unexpectedly under multiple conditions (ToolError propagation + idle process kill)

[Fauteck]

Summary

The MCP server in the add-on exits the entire Uvicorn process under at least three different conditions. With Supervisor watchdog enabled, this triggers a crashloop. With watchdog disabled, the server stays dead until manually restarted. The Webhook Proxy add-on continues running but logs MCP server unreachable until intervention.

Observed three distinct crash patterns in a single 7-hour session — at least two of them appear to be separate bugs.

Environment

• Add-on version: 7.4.1 (latest, no update available)
• Host: Home Assistant Yellow (HAOS, aarch64)
• Setup: ha-mcp add-on + Webhook Proxy add-on, accessed via Nabu Casa from Claude.ai
• Add-on options: enable_skills: true, enable_skills_as_tools: true, enable_tool_search: true, backup_hint: normal
• Watchdog: disabled (after observing crashloop)
• Conflict ruled out: the official mcp_server core integration is not installed/active

Three observed crash patterns

Pattern A — ToolError exits the entire server

A failing tool call raises ToolError (e.g. CONNECTION_FAILED because the WebSocket to http://supervisor/core couldn't be established). Instead of returning the error to the MCP client, the exception propagates to Uvicorn and shuts down the application.

2026-05-03 20:03:03 ToolError: {
                      "success": false,
                      "error": {
                        "code": "CONNECTION_FAILED",
                        "message": "Failed to connect to Home Assistant WebSocket",
                        ...
                      }
                    }
DEBUG:mcp.server.streamable_http:Terminating session: None
2026-05-03 20:03:03 INFO:     Shutting down
2026-05-03 20:03:03 INFO:     Application shutdown complete.
2026-05-03 20:03:03 INFO:     Finished server process [1]
2026-05-03 20:03:03 [INFO] MCP server stopped

Stack trace points to:

/app/.venv/lib/python3.13/site-packages/ha_mcp/tools/helpers.py:63 in raise_tool_error
    raise ToolError(json.dumps(error_response, indent=...))

Pattern B — Server exits while completely idle

This is the most surprising one. The server runs for ~6 minutes with zero requests (no tool calls, no health checks visible in the add-on log), then exits.

2026-05-03 20:52:07 INFO:     Application startup complete.
2026-05-03 20:52:07 INFO:     Uvicorn running on http://0.0.0.0:9583
                              ← 6 minutes of complete silence in the log ←
2026-05-03 20:58:23 INFO:     Shutting down
2026-05-03 20:58:23 INFO:     Application shutdown complete.
2026-05-03 20:58:23 INFO:     Finished server process [1]
2026-05-03 20:58:23 [INFO] MCP server stopped

No ToolError, no exception, no incoming request. Something is sending SIGTERM to the process. Since Supervisor watchdog is disabled, this is not the supervisor.

Pattern C — Wrapper-script kills server after a successful tool call

A tool call succeeds (HTTP 200), then ~32 s later the server is shut down. The log line ordering is the diagnostic clue:

2026-05-03 21:32:23 INFO:  127.0.0.1 - "POST /private_..." 200 OK   ← successful call
2026-05-03 21:32:55 [INFO] MCP server stopped                       ← bash wrapper FIRST
2026-05-03 21:32:55 INFO:     Shutting down                         ← Uvicorn reacts to SIGTERM
2026-05-03 21:32:55 INFO:     Waiting for application shutdown.
2026-05-03 21:32:55 INFO:     Application shutdown complete.
2026-05-03 21:32:55 INFO:     Finished server process [1]

The [INFO] MCP server stopped line uses the bash-wrapper log format (different from Uvicorn's INFO:). It appears before Uvicorn's shutdown messages, indicating the wrapper script killed the Python process and then logged that fact, after which Uvicorn shut down gracefully on the SIGTERM. This means there's a container-internal supervisor/watchdog killing the server, independent of the Supervisor-level watchdog setting.

This is consistent with the Webhook Proxy add-on independently observing the server flapping in/out of reachability:

2026-05-03 19:40:58 [ERROR] MCP server unreachable: http://127.0.0.1:9583/private_...
2026-05-03 19:42:58 [INFO]  MCP server is reachable again
2026-05-03 19:43:58 [ERROR] MCP server unreachable: http://127.0.0.1:9583/private_...
2026-05-03 19:47:58 [ERROR] MCP server still unreachable after 5 checks

Crashloop with watchdog enabled

When Supervisor watchdog is on, the above patterns cause an endless restart loop. Supervisor logs (24× in 7.5 hours):

WARNING [supervisor.addons.addon] Watchdog found app Home Assistant MCP Server is failed, restarting...
INFO    [supervisor.docker.manager] Cleaning addon_81f33d0f_ha_mcp application
INFO    [supervisor.docker.addon]   Starting Docker app ghcr.io/homeassistant-ai/ha-mcp-addon-aarch64 with version 7.4.1

Underlying connectivity issues (likely contributing, possibly orthogonal)

The supervisor log shows the WebSocket from the add-on to HA Core flapping:

INFO [supervisor.api.proxy] [81f33d0f_ha_mcp] WebSocket access from 81f33d0f_ha_mcp
INFO [supervisor.api.proxy] [81f33d0f_ha_mcp] Home Assistant WebSocket API closed

…repeating every few seconds. The add-on log also shows:

WARNING:ha_mcp.tools.smart_search:Automation config fetch budget exhausted (30.0s).
                                  Fetched 5/84 (55 failed), skipped 24 automations.
ERROR:ha_mcp.client.rest_client:WebSocket message failed: Command failed: Unknown command.
INFO:httpx:HTTP Request: GET http://supervisor/core/api/states/ "HTTP/1.1 502 Bad Gateway"

Whether these are the trigger for the crashes or a separate issue isn't fully clear, but they're frequent enough to be relevant context.

Tools observed to trigger crashes

From this user's logs (n=1, anecdotal):

• ha_search_entities — confirmed (matches [BUG] MCP connection crashes persistently when calling ha_search_entities tool #406)
• Bulk automation/script config fetches — Automation config fetch budget exhausted
• ha_get_addon, ha_manage_addon — fail with CONNECTION_FAILED when WS to supervisor is unreachable

Tools that worked in the same session without crashing:

• ha_get_addon(slug=...) — when WS happened to be up
• ha_get_updates()

Expected behavior

1. A ToolError raised inside a tool handler should be returned to the MCP client and not terminate the server.
2. The server should not exit while idle and not under load.
3. Any container-internal health/restart mechanism should at minimum log its decision (marked unhealthy because ...) so users can diagnose.

Workaround currently in use

• Disable Supervisor watchdog for the add-on (otherwise: crashloop)
• Manually restart the add-on after each crash
• enable_tool_search: true enabled (does not fully solve the problem)

Possibly related

• [BUG] MCP connection crashes persistently when calling ha_search_entities tool #406 ("MCP connection crashes persistently when calling ha_search_entities tool") — same family of issue, but this report covers crashes that occur without any tool call (pattern B) and after successful tool calls (pattern C), suggesting at least one additional bug beyond the search-tool path.

[github-actions[bot]]

❌ Evaluation failed

An error occurred:

YOLO mode is enabled. All tool calls will be automatically approved.
Approval mode overridden to "default" because the current folder is not trusted.
YOLO mode is enabled. All tool calls will be automatically approved.
Approval mode overridden to "default" because the current folder is not trusted.
�[31mGemini CLI is not running in a trusted directory. To proceed, either use `--skip-trust`, set the `GEMINI_CLI_TRUST_WORKSPACE=true` environment variable, or trust this directory in interactive mode. For more details, see https://geminicli.com/docs/cli/trusted-folders/#headless-and-automated-environments�[0m

Please check the workflow logs.

[kingpanther13]

This is a strange one. I will investigate it soon, but just to be clear has ha-mcp ever worked for you before or is this a fresh install? Trying to see if one of the latest updates maybe caused the issue, or if this is a fresh install. ALso have you rebooted HA? The nabu casa webhook addon requires a reboot of HA, but if that was the issue then you wouldn't be able to use tools or connect at all till you restarted. I did make some recent changes to the nabu casa webhook addon as well pushing it to 1.0.2 so I wonder if that could be causing an issue. I have the webhook app running right now on my installation and I"m not seeing any similar logs but I'll let it run overnight and see if anything happens.

[kingpanther13]

Tried to reproduce all three patterns against the dev addon (Fork-Dev dev92) and stable v7.4.1 over Nabu Casa, ~10 min of probing.

Pattern A — ToolError exits the server: Did not reproduce. Triggered three controlled ToolError cases (ENTITY_NOT_FOUND, SERVICE_CALL_FAILED from a bad template, SERVICE_CALL_FAILED for a nonexistent addon slug). Each returned cleanly to the client and the server stayed up.

Pattern B — idle exit at ~6 min: Did not reproduce. Server stayed alive across a ~6 min idle window plus follow-up probes.

Pattern C — kill ~32 s after a successful call: Did not reproduce. Probes at T+50, T+110, T+230, then a 5-call burst, then 4 min idle, then another probe — all OK.

One thing worth flagging on Pattern A specifically: per homeassistant-addon/start.py:391, [INFO] MCP server stopped is only logged when mcp.run() returns cleanly. If a ToolError had actually escaped to Uvicorn, the wrapper's except BaseException block would log MCP server crashed: ... instead. The original report shows stopped, not crashed — so the ToolError line preceding shutdown looks coincidental; the actual exit is from a SIGTERM, same as B and C. That collapses all three patterns to "something is sending SIGTERM despite watchdog being off" — which we can't see from inside the addon today.

---

Plan: optional in-addon kill-source diagnostics

To make this debuggable on any install hitting it, we'd like to land an opt-in diagnostic mode. Posting the plan here for feedback before opening the PR.

User-facing toggle:

• New option in the addon's Configuration tab: "Advanced debug logging" (default off)
• Description: "Captures extra diagnostic info on kill/shutdown — sender PID and memory state. Useful when reporting unexplained add-on stops or crash loops. Off by default to keep logs concise."
• Single named umbrella so future diagnostics can land under the same flag without renaming.

Toggle off (default): no behavior change. The ctypes/sigaction path is not installed.

Toggle on: start.py schedules a SIGTERM/SIGINT/SIGHUP handler that's installed after uvicorn's capture_signals() runs (otherwise uvicorn would overwrite our SA_SIGINFO via plain signal.signal). On signal:

• Capture si_pid and si_code (USER/KERNEL/TKILL) via sigaction + SA_SIGINFO (ctypes — Python's signal.signal() doesn't expose siginfo_t).
• Resolve /proc/<pid>/comm and /proc/<pid>/cmdline to name the killer (supervisor process, healthcheck binary, OOM, etc.).
• Snapshot /proc/self/status key fields: VmRSS, VmHWM, Threads, State, oom_score, oom_score_adj.
• Chain to uvicorn's saved handle_exit (SIGTERM/SIGINT) or fall through to libc-direct SIG_DFL + re-raise (SIGHUP, which uvicorn doesn't capture) so the server still shuts down cleanly — only side effect is the extra log block.

Tests: unit tests for /proc/self/status + /proc/<pid>/comm parsing, kernel ABI pinning for _SI_CODE_NAMES, install happy-path/partial/error/idempotency, and the uvicorn-overwrite scenario (snapshot + chain). Linux-only branches skipped elsewhere.

Value is independent of #1109 — even if the cause turns out to be obvious in retrospect, the addon should self-diagnose kill source on any future occurrence so we don't have to ask reporters to set up strace or auditd.

[Fauteck]

Follow-up: another 1-hour session, 13 restarts — and one captured SIGTERM with exact supervisor correlation

Captured a fresh 1-hour log window (~09:47–11:14) on the Dev channel
add-on, version 7.4.1.dev258 (same 7.4.1 series as the original
report). The server restarted 13 times in that hour, on average
every 4–10 minutes.

Add-on settings during the session:

• Start on boot: enabled
• Watchdog: started enabled, then disabled mid-session (~10:48)
• Options:

  backup_hint: normal
  enable_skills: true
  enable_skills_as_tools: false
  enable_tool_search: true
  enable_yaml_config_editing: false
  tool_search_max_results: 5
  disabled_tools: ""
  pinned_tools: ""
  verify_ssl: true
  advanced_debug_logging: true

No option changes and no updates during the hour, so neither option-save
nor an update can explain the restarts.

Caught one in the act: SIGTERM from the supervisor (PID 0, cross-namespace)

For the first time, the kill_signal_diagnostics handler in
advanced_debug_logging mode actually fired and produced output. It
caught one of the kills in this session — at 10:58:02:

================================================================================
ADVANCED DEBUG LOGGING — kill-signal diagnostics
================================================================================
Signal:         SIGTERM (15)
si_code:        SI_USER
Sender PID:     0 (cross-namespace; likely Supervisor or host process)
Sender comm:    <cross-namespace>
Sender cmdline: <cross-namespace>

Process state (from /proc/self/status):
  State: R (running)
  VmRSS:  75920 kB
  VmHWM:  83788 kB
  VmPeak: 236052 kB
  Threads: 1
================================================================================
2026-05-05 10:58:02 INFO:     Shutting down
2026-05-05 10:58:03 INFO:     Application shutdown complete.
2026-05-05 10:58:03 INFO:     Finished server process [1]
2026-05-05 10:58:03 [INFO] MCP server stopped

This correlates sub-second with the supervisor log:

2026-05-05 10:58:02.584 INFO  [supervisor.docker.manager]  Stopping addon_81f33d0f_ha_mcp_dev application
2026-05-05 10:58:04.843 INFO  [supervisor.docker.manager]  Cleaning addon_81f33d0f_ha_mcp_dev application
2026-05-05 10:58:06.069 INFO  [supervisor.docker.addon]    Starting Docker app ghcr.io/homeassistant-ai/ha-mcp-addon-dev-aarch64 with version 7.4.1.dev258

So this particular kill is unambiguously: supervisor sends SIGTERM →
container goes through Docker stop path → Uvicorn shuts down cleanly →
container restarts.

A few things worth noting from the diagnostics output:

• si_code: SI_USER rules out a kernel-initiated kill (e.g. OOM)
• VmRSS = 76 MB, VmHWM = 84 MB — far from any plausible memory limit
• Sender PID 0 from inside the container PID namespace = sender is
  outside the namespace, i.e. supervisor or host

Important caveat — this clean SIGTERM is the exception, not the rule

The supervisor log shows Stopping addon ... for this one kill — that
is the supervisor's clean stop path, typically triggered by an
explicit user/API request (UI restart, options-save, etc.). I did press
a manual restart around that time, so this particular instance is
expected.

What's notable is that for all 12 other restarts in this hour, the
kill_signal_diagnostics block did not appear at all, even though
the handler was installed. Those restarts show this pattern in the
supervisor log:

[81f33d0f_ha_mcp_dev] Home Assistant WebSocket API closed
WARNING  Watchdog found app Home Assistant MCP Server (Dev) is failed, restarting...   ← only with watchdog on
Cleaning addon_81f33d0f_ha_mcp_dev application

— note the absence of Stopping. This is the hard-kill path. The
fact that the handler never logs anything for these strongly suggests
they are SIGKILL (which can't be trapped) rather than SIGTERM.

Cross-checked with supervisor logs — watchdog is not the cause

After disabling the watchdog mid-session at ~10:48, the add-on continued
to die in the same way — the deaths just stopped being auto-restarted.
The supervisor log shows the same exit pattern in both phases:

Phase A — watchdog enabled (until ~10:48):

10:47:13.533  [81f33d0f_ha_mcp_dev] Home Assistant WebSocket API closed
10:47:14.785  WARNING  Watchdog found app Home Assistant MCP Server (Dev) is failed, restarting...
10:47:14.820  Cleaning addon_81f33d0f_ha_mcp_dev application

Phase B — watchdog disabled (after ~10:48):

10:49:48.487  [81f33d0f_ha_mcp_dev] Home Assistant WebSocket API closed
10:50:03.720  Cleaning addon_81f33d0f_ha_mcp_dev application
10:50:27.133  WARNING  App 81f33d0f_ha_mcp_dev is not running

Same exit pattern, no watchdog warning, no auto-restart. This rules out
the watchdog as the cause — it was only the mechanism that was hiding
the underlying problem by auto-restarting after each death.

What the supervisor log does not show

For every death in both phases, none of these appear at the
supervisor level:

• No OOM-kill, no memory-limit hit
• No DNS resolution errors (dns_server_failed/dns_server checks all
  pass cleanly during the window)
• No network/proxy errors
• No supervisor-initiated Stopping (except for the one manual
  restart that produced the diagnostics block above)

The supervisor learns about each unexplained death ~15 seconds after
it happens (via the Cleaning step), which means the kill originates
inside the container — consistent with the wrapper-script behaviour
described in Pattern C.

Confirmed observations from the add-on log itself

• No ToolError and no exception before any of the restarts in this
  particular hour.
• The kill_signal_diagnostics handler is installed for SIGTERM/SIGINT/SIGHUP
  on every start, but only fired once — for the manual restart at
  10:58:02. None of the other 12 restarts produced a diagnostics block.
• Each restart starts a brand-new Uvicorn process (PID 1, fresh FastMCP
  banner) — so it's a full container restart, not just an Uvicorn
  reload.
• The only error in the whole hour is one unrelated
  PythonSandboxError: Expression validation failed: Forbidden on
  ha_config_set_automation — clearly not the cause, since 12 other
  restarts happened without it.

Additional data point

The very first start after the add-on came up logs

advanced_debug_logging: uvicorn handler not detected within 10.0s; installing anyway
...kill-signal diagnostics installed for: SIGTERM, SIGINT, SIGHUP (chains to existing handlers for: SIGINT)

— note: no chain to an existing SIGTERM handler. Every subsequent
start logs chains to existing handlers for: SIGINT, SIGTERM. So on the
first boot there's a ~10 s window where Uvicorn's SIGTERM handler
isn't yet installed when the diagnostics shim runs. Probably unrelated
to the main issue (since the unexplained kills appear to be SIGKILL
anyway, bypassing handlers entirely), but worth flagging.

Summary

• One kill caught and fully attributed: clean SIGTERM from supervisor,
  matching a Stopping addon ... entry — that one was a manual restart.
• The other 12 kills in the same hour produced no diagnostics block
  despite the handler being installed → consistent with SIGKILL.
• Watchdog disabling does not stop the deaths — it only stops the
  auto-restart afterwards.
• No OOM, no memory-limit, no DNS, no supervisor-initiated stop visible
  for the unexplained kills.
• Cause appears to be internal to the container (wrapper script and/or
  Uvicorn-shutting-down on tool exception, i.e. Pattern A + Pattern C
  from the original report).

Happy to provide both full logs (add-on + supervisor) if useful — let me
know what's most helpful.

[github-actions[bot]]

❌ Analysis failed

An error occurred:

YOLO mode is enabled. All tool calls will be automatically approved.
Approval mode overridden to "default" because the current folder is not trusted.
YOLO mode is enabled. All tool calls will be automatically approved.
Approval mode overridden to "default" because the current folder is not trusted.
�[31mGemini CLI is not running in a trusted directory. To proceed, either use `--skip-trust`, set the `GEMINI_CLI_TRUST_WORKSPACE=true` environment variable, or trust this directory in interactive mode. For more details, see https://geminicli.com/docs/cli/trusted-folders/#headless-and-automated-environments�[0m

Please check the workflow logs.

[kingpanther13]

Sorry I didn't realize that the issue auto-closed. Reopening now till we figure out what is causing this. I will analyze that info and decide further steps

[kingpanther13]

Beautiful capture, thanks. The trapped kill at 10:58:02 is everything we'd hope for from the SA_SIGINFO path: cross-namespace label rendered correctly, sub-second supervisor correlation, clean SIGTERM via the Docker stop path. That one was your manual restart, expected behavior — confirms the feature itself works end-to-end.

The 12 untrapped restarts are the actual #1109. Two datapoints from your existing logs would meaningfully narrow this down — both viewable from the HA UI without CLI:

1. Add-on log → does [INFO] MCP server stopped appear right before each of the 12 unexplained restarts?

That line is logged by homeassistant-addon/start.py only when mcp.run() returns cleanly (Uvicorn's serve loop exits via should_exit). Three outcomes:

• Present for the 12 → Python exited normally without any signal. We'd be looking at something inside Uvicorn or FastMCP cleanly tearing down its serve loop on its own.
• Absent for the 12 → hard kill (SIGKILL or SIGABRT/abort). Consistent with your hypothesis. Untrappable by handler, by design.
• Mixed → multiple causes. Important to know.

2. Settings → System → Logs → Host (in the dropdown) — anything around the death timestamps?

This surfaces the host's systemd journal, which is where the kernel's OOM killer leaves a record (the addon's supervisor log doesn't include kernel events). Your VmRSS of 76 MB makes cgroup OOM unlikely, but it's a one-glance ruling-out.

Acknowledged separately:

You're right about the first-boot install gap — schedule_install_after_uvicorn's 10-second timeout can fire mid-uvicorn.Server.capture_signals(), which on a slow cold start leaves SIGTERM coverage broken until the next addon restart. Subsequent boots are faster because the image is cached, hence the asymmetry. Going to fix that separately (poll for both SIGINT and SIGTERM being captured before installing, with a longer deadline). Won't change the #1109 picture (untrappable SIGKILL doesn't care about handler ordering), but it's a real bug.

Likely follow-up after these two answers:

If the kills are confirmed SIGKILL, we can't catch them at-the-moment by design. But we can extend advanced_debug_logging with a persistent post-mortem: small JSON snapshot to /data every 10–30 s while running (memory state, oom_score, recent request, etc.), deleted on clean shutdown, surfaced at next start if still present. Won't pin the exact instant but will tell us "memory was X" / "oom_score was trending up" / "last request was Y" right before the kill — which is the missing piece for SIGKILL deaths. Holding on building it until the two datapoints above tell us whether it's the right next step.

[Fauteck]

Thanks a lot for reopening and for digging into this — really appreciate it.
Quick status: after a full HA restart (add-on restart alone isn't enough) the server runs reliably for a few hours, then slips back into patterns B and C without an obvious trigger. Feels less like a single bad call and more like accumulating state somewhere — supervisor-proxy WS sessions, FDs, or an internal counter in the wrapper would be my guess.
Just let me know which diagnostics would help most next time it degrades, and I'll capture them.

[github-actions[bot]]

⚠️ Triage bot temporarily unavailable.

The automated triage hit an internal error. Your issue will be triaged manually — no action needed on your part.

🤖 Automated triage by Issue Bot

[Fauteck]

Both datapoints checked — results below.

1. [INFO] MCP server stopped before the unexplained restarts?

Absent in all of them. The add-on log covers 15 starts; only one ends with a clean shutdown sequence — the manual restart at 10:58:02 (the trapped SIGTERM you already confirmed). For every other restart, the log goes straight from normal Uvicorn output into the next container boot (Importing ha_mcp module...) with no Shutting down / Application shutdown complete / MCP server stopped lines in between.

So this matches your SIGKILL/SIGABRT hypothesis cleanly — Python never gets the chance to log a clean exit.

2. Host log around the death timestamps?

Yes, and it's interesting — but probably not the smoking gun for #1109 itself:

• A heavy global_oom storm from 09:38–09:42 (42 OOM-kills in ~4 minutes), almost all hitting the speech-to-phrase container (phonetisaurus / python3), plus matter-server and go2rtc. constraint=CONSTRAINT_NONE and global_oom — host-wide memory pressure, not a cgroup limit.
• The MCP container itself does not appear in any OOM-kill record, but during that window dockerd logged 5 fresh sbJoin events for addon_81f33d0f_ha_mcp_dev — i.e. the MCP container was being re-created repeatedly while the storm was happening. Plausibly collateral damage from host RAM pressure.
• After 09:43 the storm stops (speech-to-phrase container gets fully deactivated), but Watchdog restarts of MCP continue until 10:48 — so the OOM storm doesn't explain all the restarts on its own.

Caveat on coverage: the Host log I can pull from the UI ends at 10:21, so it doesn't cover the later restarts in the add-on log (10:32–11:14). I can grab a longer host log next time it degrades if useful.

Net read: the unexplained restarts are untrappable kills (matches Q1), and at least the early cluster correlates with a host-wide OOM event triggered by a different add-on. Whether the later restarts are also memory-related or a separate cause is open — the persistent post-mortem snapshot you described would clearly be the right next step to find out.

[github-actions[bot]]

⚠️ Triage bot temporarily unavailable.

The automated triage hit an internal error. Your issue will be triaged manually — no action needed on your part.

🤖 Automated triage by Issue Bot

[Fauteck]

P.S. I've now disabled both Speech-to-Phrase and Matter Server (the two add-ons that dominated the OOM-kill list) and added an 8 GB swap file as a safety net. Will report back if the unexplained MCP restarts continue under those conditions — that should help separate "host RAM pressure side-effect" from "actual #1109 root cause."

[github-actions[bot]]

🤖 Issue Triage Bot is analyzing this issue...

This may take a minute. I'm:

• Fetching the full issue thread
• Searching for related issues
• Researching relevant code and documentation

I'll update this comment when complete.

[kingpanther13]

Ok this is pointing more toward an issue with your HA in general. I don't think that Enhancing the advanced debug logging feature will help, but I do think that installing the Glances addon/integration will help you immensely. I personally use it, it gives a large wealth of information and should be able to help you pinpoint what exactly is going on. I think it only shows stuff in realtime by default but I think that there's a way to set it up so it saves logs too.

[kingpanther13]

Any updates on your side? Did killing speech to phrase fix the issue for you? Just wondering if I can close the issue or if we need to do more on our side.

[kingpanther13]

I'm going to convert this to a discussion, please @ me if you have any more issues or feel free to reopen if you feel there's anymore we can do on our side. Hoping the issue is resolved for you now!

[Fauteck]

After disabling Speech-to-Phrase and Matter Server (the main global_oom offenders) and adding an 8 GB swap file, the MCP server has been running for two days without a single unexplained restart — across idle stretches and tool-heavy bursts. Neither Pattern B nor C has reappeared.
So in my case it was host-wide RAM pressure as a side effect, not ha-mcp itself. Thanks @kingpanther13 for the patient diagnosis and the Glances tip — installed it as an early-warning. Happy to leave this closed. 👍