Skip to content

An unreadable settings.json silently disables Lite's MCP endpoint, and only says "defaults are in use" #2431

Closed

Description

@erikdarlingdata

Split out of #2425, which fixed the settings loaders' silent-reset. McpSettings.Load has the same bare catch and a worse consequence.

        catch
        {
            return new McpSettings();
        }

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).

Activity

  1. added a commit that references this issue on Aug 21, 2026
  2. erikdarlingdata commented on Aug 21, 2026

    @erikdarlingdata
    OwnerAuthor

    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.

  3. added a commit that references this issue on Aug 21, 2026
  4. added a commit that references this issue on Aug 24, 2026
    1354e4c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions