Stagger MCP server initialization and retry on timeout

[yassineMouttalib]

When multiple MCP context servers start simultaneously during project load, the GPUI executor gets overwhelmed by concurrent process spawns and JSON-RPC handshakes. This is especially visible when using NPX to launch servers, which adds its own startup overhead — often causing timeouts as described in #38252.

While configurable timeouts were added in #45378, the root cause is that spawning multiple servers concurrently starves the executor of IO resources. This PR addresses that directly with two changes:

Staggered initialization

Wait 3 seconds after project load before starting any MCP servers, then start them sequentially with 500ms between each. This gives the executor time to settle and prevents IO starvation during the critical startup window.

Retry on timeout

When a server fails to start with a timeout error, retry up to 3 times with a 2-second delay between attempts. Non-timeout errors (including OAuth 401 responses handled by resolve_start_failure) skip the retry loop and are handled immediately.

Release Notes:

• Improved MCP context server startup reliability by staggering server initialization and retrying on timeout

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @yassineMouttalib on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[yassineMouttalib]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[smitbarmase]

Thanks for taking the time on this.

I don't think this is the right direction. The context_server_timeout setting from #45378 already covers global default and per-server overrides (up to 10 minutes), and an affected user on #38252 confirmed it resolved the issue for them. The real cause in the npx cases is just cold-cache install exceeding the 60s default, not executor starvation, I couldn't reproduce that on a typical machine.

The stagger and 3s startup delay don't shorten install time, and the startup delay fires on every settings or registry change, not just startup. I think the right lever is the timeout setting itself, the default is probably just too low for cold npx.

The retry-on-timeout idea has some independent value (cold attempt fails, warm cache succeeds), so that could be worth pulling out separately, which is likely why it's been working for you.

I'll close this one for now. Feel free to follow up or open a new PR with just the retry-on-timeout idea, I think that's worth surfacing to users. Thanks again.