You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
An unreadable settings.json silently disables Lite's MCP endpoint, and only says "defaults are in use" #2431
Split out of #2425, which fixed the settings loaders' silent-reset. McpSettings.Load has the same bare catch and a worse consequence.
catch{returnnewMcpSettings();}
An unreadable or malformed settings.json therefore returns defaults — and the default is MCP off. So the same trailing comma that #2425 now reports as "every setting is at its default" also silently disables the MCP endpoint, and the startup report added by #2425 covers it only in general terms. It does not say the MCP server is one of the things that just turned itself off.
That matters because of who notices and how. A wrong alert threshold is visible the next time an alert does or does not fire, from a UI the user is already looking at. A disabled MCP endpoint is invisible from the app entirely: it presents as an agent or client failing to connect, on a different machine, to a service that reports itself healthy. The person debugging it has no reason to suspect a JSON comma in a file on the monitored workstation.
What to do
Reuse SettingsFileGuard from #2425 rather than adding a second read path — that guard already distinguishes absent (legitimate, silent) from present-but-unparseable (never legitimate), which is exactly the distinction this needs. Two behaviours follow from it:
Say which capability was lost, not just that defaults are in use. "settings.json could not be read, so the MCP server is disabled" is actionable; "every setting is at its default" is not, to someone who is not looking at the app.
Consider whether MCP-off is the right failure mode at all. It is the safe default for a file that has never existed, and arguably the wrong one for a file that exists and is broken — the user configured this endpoint deliberately and a syntax error elsewhere in the document silently revokes it. Refusing to start with a clear error may be better than starting in a state the operator did not ask for and cannot see. That is a judgment call worth making explicitly rather than inheriting from new McpSettings().
Related: #2425 (the guard and the startup report), #2418 (the sample file that makes hand-editing likelier).
Fixed on dev by #2435, and the failure-mode question I asked got a two-part answer that I think is right.
MCP stays off — mcp_enabled and mcp_port are consent and address for a TCP listener, and a file that did not parse supplies neither. Starting anyway opens a port nobody asked for at a guessed address, and since #2414 the firewall rule follows the configured port, the guess is not even where a client is aimed.
But it is not fatal, and that is the half worth stating: Lite is the collector. Refusing to start collects nothing, alerts on nothing, and leaves a history hole that repairing the JSON later does not backfill — while removing the very window the person repairing the file would work in. #2425 already made that call for the other 88 settings, and one file must not have two failure modes depending on which loader happened to read it first.
So off was never the defect. Silence was, and three surfaces now name the lost capability: StartMcpServerAsync logs it at the one moment Lite knows, #2425's startup line and modal name the MCP server among what turned itself off, and the Settings window stops reporting "Disabled" over a file it never read — it asks the running host for its port rather than re-reading a file that may still be broken.
Two shapes SettingsFileGuard cannot see are handled separately, since the document parses fine in both: a quoted "true" and a quoted port are checked by JSON value kind and name the offending key.
The review round caught something real and worth recording: UpdateMcpStatus runs only in the constructor and SaveButton_Click never closes the window, so the warning outlived the file it was describing. It re-reads after a save now.
Activity
Merge pull request #2435 from erikdarlingdata/fix/2431-mcp-endpoint-l…
erikdarlingdata commentedon Aug 21, 2026
Fixed on
devby #2435, and the failure-mode question I asked got a two-part answer that I think is right.MCP stays off —
mcp_enabledandmcp_portare consent and address for a TCP listener, and a file that did not parse supplies neither. Starting anyway opens a port nobody asked for at a guessed address, and since #2414 the firewall rule follows the configured port, the guess is not even where a client is aimed.But it is not fatal, and that is the half worth stating: Lite is the collector. Refusing to start collects nothing, alerts on nothing, and leaves a history hole that repairing the JSON later does not backfill — while removing the very window the person repairing the file would work in. #2425 already made that call for the other 88 settings, and one file must not have two failure modes depending on which loader happened to read it first.
So off was never the defect. Silence was, and three surfaces now name the lost capability:
StartMcpServerAsynclogs it at the one moment Lite knows, #2425's startup line and modal name the MCP server among what turned itself off, and the Settings window stops reporting "Disabled" over a file it never read — it asks the running host for its port rather than re-reading a file that may still be broken.Two shapes
SettingsFileGuardcannot see are handled separately, since the document parses fine in both: a quoted"true"and a quoted port are checked by JSON value kind and name the offending key.The review round caught something real and worth recording:
UpdateMcpStatusruns only in the constructor andSaveButton_Clicknever closes the window, so the warning outlived the file it was describing. It re-reads after a save now.Merge dev, keeping #2431's MCP status re-read on the one write
Say that the MCP endpoint is what an unreadable settings.json cost