fix(cli): distinguish an unreadable MCP enablement config from a missing one - #29445

Summary

A corrupt mcp-server-enablement.json currently fails open: every MCP server the
user deliberately disabled is reported as enabled, connected, and its tools are
exposed to the model. The next disable() then writes a fresh one-entry file
over the corrupt one, erasing every other entry.

Both follow from readConfig() collapsing "the file does not exist" and "the
file exists but cannot be read" into the same {}.

Details

readConfig() returned {} for a SyntaxError exactly as it did for ENOENT.
Downstream, isFileEnabled() reads state?.enabled ?? true, so an empty config
means everything is enabled — a trust boundary that fails in the permissive
direction. disable() then round-trips that same {} back to disk with one key
added, and the unreadable contents are gone.

This PR keeps the two cases apart:

• readConfig() returns a ReadConfigResult discriminated on
  ok / missing / unreadable. Only missing yields an empty config.
• isFileEnabled() fails closed on unreadable. A file that cannot be read
  may disable this server, and we cannot tell which.
• enable() and disable() refuse to write on unreadable, throwing
  McpServerEnablementConfigError, so the file on disk is preserved for the
  user to repair.
• Valid JSON of the wrong shape is treated as unreadable too. {"playwright": "off"} parses fine, leaves state.enabled undefined, and fails open by the
  same ?? true. Entries carrying unknown extra fields are still accepted so
  older clients tolerate configs written by newer ones.
• The error is reported once per stretch of failures rather than on every read —
  isFileEnabled() runs for every server on every connection attempt — and now
  names the file path and the remedy.

Call sites that write: gemini mcp enable/disable and /mcp enable|disable now
print the refusal instead of rejecting. autoEnableServers() (extension enable)
stops and returns what it managed, since nothing can be re-enabled while the
file is unreadable.

Deliberately out of scope: canLoadServer() still reports blockType: 'enablement' with "Run 'gemini mcp enable '" when a server is blocked
this way. Distinguishing "disabled" from "config unreadable" there means
widening the EnablementCallbacks boolean contract that packages/core
consumes. The emitted error explains the real cause in the meantime.

writeConfig is left non-atomic, exactly as on main — it is byte-identical
between the two, and this PR only changes its two call sites. A truncate-then-
write can still be observed mid-tear by a second gemini process, which now
reads as corruption. Note the direction though: on main that same tear made
disable() read {}, add one key and permanently erase every other entry;
here it refuses to write. A tmp-file + rename write (the pattern already used
in trust.ts, projectRegistry.ts and integrity.ts) is a separate change and
belongs in its own PR.

Related Issues

Fixes #28786

How to Validate

Unit tests (14 existing + 15 added, all green). 10 of the added cases fail on
main and are direct regression tests for the two defects:

npx vitest run src/config/mcp/mcpServerEnablement.test.ts --root packages/cli

End to end, against a scratch home so your real config is untouched:

Setup, then the part that reproduces on this branch alone:

npm run bundle
CLI="$PWD/bundle/gemini.js"   # `gemini` is not on PATH from a source checkout --
                              # CONTRIBUTING suggests an alias or `npm link` instead.
                              # Do NOT use a globally installed `gemini` here: it would
                              # run the released build, without this change.

export HOME=$(mktemp -d) && mkdir -p "$HOME/.gemini" "$HOME/proj"
printf '{"mcpServers":{"playwright":{"command":"echo"},"github":{"command":"echo"},"other":{"command":"echo"}}}' \
  > "$HOME/.gemini/settings.json"

# a config that disables one server, then loses its tail to a truncated write
printf '{"playwright": {"enabled": false}, "github": ' \
  > "$HOME/.gemini/mcp-server-enablement.json"
cd "$HOME/proj"
export GEMINI_CLI_TRUST_WORKSPACE=true   # the scratch dir is not a trusted folder

node "$CLI" mcp list

Observed on this branch (macOS):

Configured MCP servers:

Failed to read MCP server enablement config at <path>. Every MCP server is
treated as disabled until the file is repaired or deleted.
○ playwright: echo  (stdio) - Disabled
○ github: echo  (stdio) - Disabled
○ other: echo  (stdio) - Disabled

On main, the same command reports playwright as enabled and connects it.

The write-refusal half needs #29444 applied on top. On current main,
gemini mcp enable|disable exits early with "Server not found" for every server —
a separate bug, fixed in #29444 — so the write path here is unreachable from the CLI
until that lands. With both applied:

node "$CLI" mcp disable other
node "$CLI" mcp enable playwright
md5 "$HOME/.gemini/mcp-server-enablement.json"   # unchanged by both attempts

Error: Cannot update MCP server enablement: <path> exists but could not be read.
Repair or delete that file and retry. Until then every MCP server is treated as disabled.

with the file byte-identical (same md5) after both refused writes. Every path here is
covered by unit tests either way. The two branches touch adjacent lines of
enableDisable.ts; whichever lands second needs a one-line import rebase.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed) — docs/tools/mcp-server.md, the one place mcp-server-enablement.json is documented
• Added/updated tests (if needed)
• Noted breaking changes (if any) — behaviour change, not API: an unreadable
  config now disables MCP servers rather than silently enabling them, and
  enable/disable refuse to write until it is repaired. That is the point of
  the fix; a missing config behaves exactly as before.
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

The change is filesystem-and-JSON only, with no platform-specific paths beyond
Storage.getGlobalGeminiDir(), which it does not touch.

🤖 Generated with Claude Code