fix(cli): stop an untrusted workspace wiping its own settings.json - #29466

Summary

gemini mcp add run in a folder the user has not trusted silently destroys that
project's .gemini/settings.json, keeping only the key it just wrote, and reports
success. Untrusted is the default state for any folder not explicitly trusted, so this is
a normal path. Reproduces on the published 0.60.0 and on main @ d5b3e3acc.

Fixes #29465.

Details

Four steps, all in packages/cli/src:

1. config/settings.ts — an untrusted workspace is replaced by an emptied copy:

   this.workspace = isTrusted ? workspace : this.createEmptyWorkspace(workspace);

   createEmptyWorkspace spreads the original, so the copy keeps the real path and
   leaves readOnly unset.

2. setValue() resolves through forScope(Workspace), gets that copy, and persists it —
   isPersistable is !settingsFile.readOnly, so undefined means writable.

3. saveSettings() writes originalSettings — {} plus the one new key — to the real path.

4. utils/commentJson.ts — applyKeyDiff is sync-by-omission: every key on disk and
   absent from the update is deleted. Correct when originalSettings mirrors the file;
   destructive when the in-memory copy was deliberately emptied.

The fix

createEmptyWorkspace marks the copy readOnly: true. That is the same mechanism
loadSettings already uses to keep the workspace unwritable when it is the home
directory (readOnly: storage.isWorkspaceHomeDir()), so this is the existing idiom rather
than a new concept. saveSettings has exactly one caller and it is gated on
isPersistable, so this closes the write path completely.

setValue also now warns when a workspace write did not reach disk. Callers such as
mcp add log success immediately after setValue returns, so staying silent reads as
"saved". Only User and Workspace are ever written (nothing in the tree calls
setValue(SettingScope.System…)), so this cannot fire for the intentionally read-only
system scopes.

Deliberately out of scope

What should happen instead of the write is left to you, and tracked in #29465: refuse
outright with "this folder is not trusted", or write through to _workspaceFile so an
explicit mcp add still lands. Both are behaviour decisions on a trust boundary. This PR
only stops the destruction and stops the silence.

One consequence of that: on an untrusted folder mcp add now prints the warning and
then still prints its own success line. Suppressing the second needs a result threaded
back to each of the four callers (mcp add, mcp remove, gemma setup, hooks migrate),
which is the same design decision. The warning is printed first so the user sees it.

Related Issues

Fixes #29465

How to Validate

npx vitest run src/config/settings-untrusted-write.test.ts --root packages/cli

New file, 6 cases, real files in a temp dir rather than fs mocks — what lands on disk is
the whole point. 3 fail without the source change; the others are controls asserting
the trusted path is untouched.

End to end:

npm run bundle
CLI="$PWD/bundle/gemini.js"
export HOME=$(mktemp -d) && mkdir -p "$HOME/.gemini" "$HOME/proj/.gemini"
cat > "$HOME/proj/.gemini/settings.json" <<'JSON'
{
  "ui": { "theme": "GitHub" },
  "context": { "fileName": "GEMINI.md" },
  "mcpServers": { "existing": { "command": "echo" } }
}
JSON
cd "$HOME/proj"
md5 "$HOME/proj/.gemini/settings.json"
node "$CLI" mcp add newsrv echo          # untrusted: the default
md5 "$HOME/proj/.gemini/settings.json"   # must be unchanged

GEMINI_CLI_TRUST_WORKSPACE=true node "$CLI" mcp add newsrv echo   # control
cat "$HOME/proj/.gemini/settings.json"   # merges: existing AND newsrv, ui/context intact

On main the first mcp add leaves only {"mcpServers":{"newsrv":…}} — ui, context
and the pre-existing existing server all gone.

Observed on this branch (macOS, node v22.13.0): md5 identical across the untrusted run,
warning printed, and the trusted control merges correctly.

Suites on this branch: src/config/ + src/commands/mcp/ → 41 files, 956 passed.
Full npm run test -w packages/cli → 466 of 467 files pass; the one failure is
src/gemini.test.tsx, which fails the same 9 tests on clean main in this checkout
(an untrusted-workspace environment issue — I re-ran it on main to confirm the lists are
identical, since two of those nine are trust-related and this change touches trust).
npm run typecheck -w packages/cli and eslint packages/cli/src/config/ both clean.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed) — no user-facing documented
  behaviour changes; the fix restores what the docs already imply
• Added/updated tests (if needed)
• Noted breaking changes (if any) — none. Workspace settings in an untrusted folder
  were never meant to persist; today they persist by destroying the file.
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

No platform-specific paths involved; the tests use os.tmpdir() and path.join, so they
run identically on the Windows shard.

🤖 Generated with Claude Code