fix(cli): an unreadable extension-enablement config re-enables every extension - #29481

Summary

An unreadable extension-enablement.json silently re-enables every extension the user
disabled, and the next enable/disable/remove then erases the rest of the file.

Extensions can contribute MCP servers, tools, commands and hooks, so re-enabling one the
user switched off is a trust event, not a preference reset.

This is the same defect #29445 fixes for mcp-server-enablement.json, in the sibling
file. The two are worth reading together.

Details

readConfig() collapses a JSON.parse failure or a zod schema failure into the same {}
it returns for ENOENT:

} catch (error) {
  if (error instanceof Error && 'code' in error && error.code === 'ENOENT') {
    return {};
  }
  coreEvents.emitFeedback('error', 'Failed to read extension enablement config.', error);
  return {};
}

Downstream, isEnabled() starts from let enabled = true ("Extensions are enabled by
default"), so an empty config means everything is on. Then writeConfig() serialises
the whole map unconditionally —

fs.writeFileSync(this.configFilePath, JSON.stringify(config, null, 2));

— so enable() (and disable(), which delegates to it) and remove() persist that {}
plus one key, dropping every other entry.

What changed

• readConfigResult() returns a result discriminated on ok / missing / unreadable.
  Only missing yields an empty config.
• isEnabled() fails closed on unreadable.
• enable() and remove() refuse to write, throwing ExtensionEnablementConfigError,
  so the file survives for the user to repair. Both call sites in extension-manager.ts
  already sit behind the try in handleDisable/handleEnable, which is how
  "Extension with name X does not exist." is already surfaced.
• Valid JSON of the wrong shape is unreadable too — {"alpha": "disabled"} parses
  fine and fails open by the same route.
• The error is reported once per stretch of failures rather than once per read, and
  now names the path and the remedy. isEnabled runs per extension per startup; on main
  a single extensions disable printed the message four times.
• readConfig() keeps its signature for existing callers; every production path inside
  the class now goes through readConfigResult().

Related Issues

Same defect class as #29445 (mcp-server-enablement.json).

How to Validate

npx vitest run src/config/extensions/extensionEnablement.test.ts --root packages/cli

7 cases added; 6 fail without the source change. The seventh is a control asserting a
missing file still behaves exactly as before.

End to end, against a scratch home:

npm run bundle
CLI="$PWD/bundle/gemini.js"
export HOME=$(mktemp -d) && mkdir -p "$HOME/proj"
for n in alpha beta gamma; do
  mkdir -p "$HOME/.gemini/extensions/$n"
  printf '{"name":"%s","version":"1.0.0"}' "$n" > "$HOME/.gemini/extensions/$n/gemini-extension.json"
done
cd "$HOME/proj" && export GEMINI_CLI_TRUST_WORKSPACE=true

node "$CLI" extensions disable alpha
node "$CLI" extensions disable beta
node "$CLI" extensions list          # alpha/beta: Enabled (User): false

# truncate three bytes, as an interrupted write would
python3 -c "import io,sys;p=sys.argv[1];s=io.open(p).read();io.open(p,'w').write(s[:-3])" \
  "$HOME/.gemini/extensions/extension-enablement.json"

node "$CLI" extensions list          # on main: alpha/beta flip to true
node "$CLI" extensions disable gamma # on main: file now contains ONLY gamma

On main: the truncation flips alpha and beta to Enabled (User): true, and the
disable gamma afterwards leaves a file containing only gamma — both disables gone.

On this branch: both stay false, one error line names the file, and the write is refused
with the file byte-identical (verified by md5).

Suites on this branch: src/config/ + src/commands/extensions/ → 47 files, 1006
passed. Full npm run test -w packages/cli → 465 of 466 files pass; the one failure
is src/gemini.test.tsx, which fails the same 9 tests on clean main in this checkout
with the identical FatalUntrustedWorkspaceError (my local checkout is not a trusted
folder). I compared the failure reason against a main run rather than just the count,
since two of those nine are hooks-and-trust tests and extensions contribute hooks.
npm run typecheck -w packages/cli and eslint packages/cli/src/config/extensions/ both
clean.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed) — no documented behaviour
  changes; extension-enablement.json is not described in /docs
• Added/updated tests (if needed)
• Noted breaking changes (if any) — behaviour change, not API: an unreadable config
  now disables extensions rather than silently enabling them, and enable/disable/remove
  refuse to write until it is repaired. 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

Filesystem-and-JSON only; no platform-specific paths beyond
ExtensionStorage.getUserExtensionsDir(), which is untouched.

🤖 Generated with Claude Code