gemini-cli - 💡(How to fix) Fix advanced.autoConfigureMemory ignores settings when GEMINI_CLI_HOME is set

What happened?

The lightweight CLI bootstrap in packages/cli/index.ts reads advanced.autoConfigureMemory before loading the full settings system. When GEMINI_CLI_HOME is set, that bootstrap path looks for settings.json directly under $GEMINI_CLI_HOME.

The rest of the storage/settings layer treats GEMINI_CLI_HOME as the replacement home directory and resolves the user settings file to $GEMINI_CLI_HOME/.gemini/settings.json via Storage.getGlobalSettingsPath().

As a result, users who correctly place their settings at $GEMINI_CLI_HOME/.gemini/settings.json cannot disable the early memory relaunch with:

{
  "advanced": {
    "autoConfigureMemory": false
  }
}

The setting is silently ignored during initial boot, and the parent process may still relaunch the CLI with an auto-generated --max-old-space-size value.

What did you expect to happen?

The early bootstrap path should read the same global user settings file as the normal settings loader. With GEMINI_CLI_HOME=/tmp/gemini-home, both paths should resolve user settings to /tmp/gemini-home/.gemini/settings.json, so advanced.autoConfigureMemory: false is honored consistently.

Client information

Observed by inspecting current main at commit 630ecc21b.

Platform used for local inspection: Linux.

Login information

Not authentication-dependent.

Anything else we need to know?

This is separate from the documentation issue about where settings should live when GEMINI_CLI_HOME is set. The documented storage behavior is already $GEMINI_CLI_HOME/.gemini/settings.json; the bootstrap relaunch path is the inconsistent path.