Prompts queue indefinitely when all configured MCP servers are skipped

[LyalinDotCom]

What happened?

When at least one MCP server is configured, prompt submission can stay queued forever even when all configured servers are effectively skipped (for example user-disabled, blocked by policy, or otherwise not started).

In the interactive CLI, submitting a normal prompt shows:

Waiting for MCP servers to initialize... Slash commands are still available and prompts will be queued.

The queue never drains, so non-slash prompts never execute.

Reproduction

1. Configure one or more MCP servers in settings.
2. Ensure all configured MCP servers are skipped at startup (for example, disable them with MCP enablement settings so /mcp list shows disabled).
3. Start a new Gemini CLI session.
4. Submit a normal prompt (not a slash command).
5. Observe that prompts are queued indefinitely behind MCP initialization.

What did you expect to happen?

If all configured MCP servers are skipped and no discovery work is actually running, MCP discovery should transition to COMPLETED and normal prompts should execute immediately.

Client information

Client Information

Gemini CLI version: 0.29.0-nightly.20260203.71f46f116
Platform: macOS (Darwin 25.2.0, arm64)
Node: v22.18.0
npm: 10.9.3

Behavior observed in interactive CLI with configured MCP server(s) shown as disabled by `/mcp list`.

Login information

Repro appears independent of login method; issue is in MCP readiness/discovery state handling.

Anything else we need to know?

Likely state-machine gap in configured server startup:

• startup sets global MCP discovery state to IN_PROGRESS when configured servers exist;
• skipped servers can return before any discovery promise is created;
• when all servers are skipped, global state may never transition to COMPLETED.

This leaves UI readiness false and prompt queue blocked.