Settings migration replaces ${VAR} placeholders in the same subtree with their expanded value

Finding: In Gemini CLI 0.63.0-nightly (commit fe6350238, macOS, per the reporter), the first-startup migration of a deprecated key in settings.json can rewrite a ${VAR} placeholder in the same subtree as its expanded value, so the environment variable stops controlling that setting. This is an external report and was not reproduced by KFA. Source: https://github.com/google-gemini/gemini-cli/issues/29556 Reported reproduction: the issue puts ui.autoThemeSwitching as a ${TEST_AUTO_THEME:-false} placeholder next to the deprecated ui.accessibility.disableLoadingPhrases. After one startup with TEST_AUTO_THEME=true, the file reportedly holds a literal true for autoThemeSwitching, and a later start with the variable set to false still reads true (https://github.com/google-gemini/gemini-cli/issues/29556). The reporter says the same happens for other subtree-rewriting migrations: general.disableAutoUpdate, general.disableUpdateNag, context.fileFiltering.disableFuzzySearch, ui.accessibility.enableLoadingPhrases, tools.approvalMode and the experimental.* ones. No error message is shown. Reported mechanism (not maintainer-confirmed): LoadedSettings keeps an expanded settings view and an originalSettings view that is what gets persisted. The report says setValue preserves placeholders, but the migration builds subtrees from the expanded view and passes the whole subtree to setValue, so siblings are written back resolved. A subtree without a deprecated key is reportedly untouched. A contributor comment on the thread reaches the same conclusion from code reading (https://github.com/google-gemini/gemini-cli/issues/29556#issuecomment-5895082965). Another commenter cautions that simply switching to originalSettings would hand unexpanded values to the runtime view, because setValue writes to both (https://github.com/google-gemini/gemini-cli/issues/29556#issuecomment-5896001689). Fix status: a commenter says PR #29564 preserves raw placeholders in persisted settings while keeping runtime values expanded, with tests including a sibling-placeholder case (https://github.com/google-gemini/gemini-cli/issues/29556#issuecomment-5905794323 and https://github.com/google-gemini/gemini-cli/issues/29556#issuecomment-5907385185). On 2026-10-07 the same commenter said it was ready for review and asked for a help-wanted label (https://github.com/google-gemini/gemini-cli/issues/29556#issuecomment-6032295663). The PR itself was not supplied, so its merge state and any release are unknown; the issue is still open. Practical implication, as a hypothesis from the reports: users who keep ${VAR} placeholders in settings.json beside deprecated keys may want to check whether the file was rewritten with literal values after upgrading. No workaround is given in the sources, and no release containing a fix is evidenced.