Hi @eliird — this PR currently has merge conflicts with main (mergeable_state: dirty). Could you rebase onto the latest main and resolve them when you get a chance? Happy to take another look once it's clean. Thanks!

Will do

Hi, during the rebase I had to make a few additional adjustments to fit the current codebase — wanted to be transparent about what changed:

• packages/cli/src/config/config.ts: Resolved the merge conflict in loadCliConfig — upstream removed mergeMcpServers, activeExtensions, and the old loadHierarchicalGeminiMemory call. Adapted the --mcp-config logic to inline parseMcpConfig directly into the mcpServers field of the Config constructor, preserving CLI-over-settings precedence.
• packages/cli/src/commands/auth/handler.ts: Added mcpConfig: undefined to the minimalArgv object — the CliArgs interface now requires it and the build was failing with a TS2741 error.
• packages/cli/src/config/config.test.ts: The tests used the old loadCliConfig signature (4 args including
  ExtensionEnablementManager). Upstream refactored it to (settings, argv). Updated all --mcp-config tests to use the new signature.

@wenshao could you take a look at it when you have time?

@eliird Thanks for the contribution! This PR is currently showing merge conflicts. Could you please rebase or merge the latest main and resolve the conflicts when you get a chance?

Thanks for the work — the implementation reads cleanly and the test coverage hits the key paths (wrapper, no-wrapper, override, allow-list filter, empty). Two items before this can land:

1. Rebase required (blocker)

The branch conflicts with current main in two files:

• packages/cli/src/config/config.ts — the mcpServers: block on main was wrapped in a bareMode ? {} : ... ternary. The parseMcpConfig merge needs to live inside the non-bareMode branch, e.g.:

  mcpServers: bareMode
    ? {}
    : (() => {
        const base = settings.mcpServers || {};
        const cliMcpServers = parseMcpConfig(argv.mcpConfig);
        return cliMcpServers ? { ...base, ...cliMcpServers } : base;
      })(),

• packages/cli/src/commands/auth/handler.ts — the inline minimalArgv: CliArgs = { ... } was extracted into a loadAuthConfig(settings) helper on main, so the mcpConfig: undefined hunk no longer has a place to go (the helper handles all CliArgs fields internally). Just drop that hunk after rebase.

2. Nice-to-haves on parseMcpConfig (non-blocking)

• Path-vs-inline detection is ambiguous on typos. --mcp-config /tmp/typo.json (missing path) falls through to the JSON-parse branch and reports Unexpected token / in JSON, which is confusing for users who intended a file path. Distinguishing file vs. inline up-front — e.g. mcpConfigArg.trimStart().startsWith('{') selects inline JSON, otherwise treat as a file path and surface a clear "file not found" error — would give a better failure mode.

• Error message can leak file contents. When JSON.parse fails on file content, the wrapped errorMessage may include a snippet of that content (e.g. accidentally pointing --mcp-config at a non-JSON file). Limiting the wrapped message to the path keeps the error informative without surfacing file bytes:

  throw new FatalConfigError(
    `Invalid MCP configuration in ${mcpConfigArg}: ${errorMessage}`,
  );

Once rebased we can move to merge — the rebase is the only true blocker.

@wenshao Sorry, I have been busy last week and was not able to respond. I will rebase it today.

@wenshao I rebased the main. Can you take a look at it when you have time.

Thanks @eliird — merged in 8896f93.

The two small UX nits I flagged earlier were non-blocking, but worth a follow-up PR when you have time:

1. Path-vs-inline detection on typos. --mcp-config /tmp/typo.json (file doesn't exist) currently falls through to the inline-JSON branch and reports Unexpected token / in JSON, which is confusing for users who clearly intended a file path. Detecting intent up front — e.g. mcpConfigArg.trimStart().startsWith('{') selects inline JSON, otherwise treat as a file path and surface a clear "file not found" error — would give a much better failure mode.

2. Error message can leak file contents. When JSON.parse fails on file content, the wrapped errorMessage may include a snippet of the file bytes (e.g. accidentally pointing --mcp-config at a non-JSON file). Limiting the wrapped message to the path keeps the error informative without surfacing file content:

   throw new FatalConfigError(
     \`Invalid MCP configuration in \${mcpConfigArg}: \${errorMessage}\`,
   );

No rush — happy to review whenever you get to it.