Claude Code headless MCP: a failed first connect is now retried

Since 2.1.283, headless Claude Code retries a remote MCP server whose first connect fails transiently. What to check in a CI run that calls Sume.

4 min readSume
All posts

In headless mode, Claude Code 2.1.283 and later retry a remote MCP server whose first connect fails transiently, without waiting for the slowest server to finish connecting. A CI job that calls the Sume server therefore no longer has to wait on an unrelated slow server before Sume gets its second try.

This is from the Claude Code changelog entry dated September 25, 2026, read 2026-10-01. The Sume details are from OAuth and API keys.

What did the changelog change?

The line reads: improved MCP startup in headless mode: a remote server whose first connect fails transiently is now retried without waiting for the slowest server to finish connecting. It is about connection startup, so it concerns claude -p runs and other non-interactive sessions, not the interactive /mcp screen.

Which credential should a CI job use for Sume?

An API key. OAuth needs a browser consent step, which a headless runner does not have. Sume's docs say API-key remote MCP stays available for automation that does not speak OAuth: send Authorization: Bearer $SUME_API_KEY or x-api-key. An API-key session sees the full hosted tool set, so scope the key and keep it in your CI secret store.

Credential choice for a headless Sume MCP run, from the docs, read 2026-10-01.
CredentialTools visibleFits CI?
OAuth with mcp:readRead-only toolsNeeds an interactive sign-in first
OAuth with mcp:read + mcp:writeFull hosted tool setNeeds an interactive sign-in first
API keyFull hosted tool setYes, as a bearer or x-api-key header

What should the job check before it spends?

Have the first step call mcp_health, which per the quickstart confirms the endpoint, the auth source and the safety posture, and tools_list to confirm the tools the job needs are visible. Only then submit. A retried connect that succeeds late still leaves you with the same tool set, so a check at the start is cheap insurance.

Can a retry cause a duplicate paid call?

The retry is of the connection, before any tool call is made, so it does not itself submit anything. Paid and write calls still need an idempotency_key; derive it from the CI run's task, not from a timestamp, so a rerun of the same job reuses the key. Add dry_run=true on the first pass of a new pipeline to preview cost.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume