tengu_mcp_connect_timeout_retry
A Claude Code feature flag, read out of the shipped bundle. It has been in the build since v2.1.227, including the newest one read.
MCP connect timeouts now respect the global timeout and get retried instead of failing.
Not Anthropic's. This is the line from the earliest changelog entry here that named it, v2.1.227.
In the changelogs
9Releases whose published page names tengu_mcp_connect_timeout_retry.
-
v2.1.307
MCP connection timeouts can be reported as suspended
When connecting to an MCP server times out, Claude Code can now report it as a suspension rather than a plain timeout
gate cited by this entry
-
v2.1.301
Background tasks pass more detail when they wake Claude up
A background task that wakes Claude now passes along where its prompt came from and details about its notices
gate cited by this entry
-
v2.1.292
Slow-starting local MCP servers are no longer wrongly remembered as older servers
A local MCP server that answered the protocol check late is no longer remembered as an older server after a connection timeout
gate cited by this entry
-
v2.1.290
MCP connection reports now include startup timing and proxy failure details
Claude Code's MCP connection reports now record how long it had been running, when the first tool list arrives, and proxy refusal codes
gate cited by this entry
-
v2.1.288
MCP tool results too large to read now warn that the tool may have run
An MCP reply too large or unreadable to accept now gets a new error telling Claude the tool may have run, and no automatic retry
gate cited by this entry
-
v2.1.287
MCP calls guard connection error tracking while they run
MCP tool calls and resumed tasks now hold a guard on connection error tracking for as long as each call runs
gate cited by this entry
-
v2.1.274
MCP connect-timeout retry and legacy SSE fallback gates referenced
MCP connection code references two settings controlling connect-timeout retries and legacy SSE fallback
named in this entry, gate cited by this entry, found in this entry's text
-
v2.1.227
MCP connection timeouts are retried and never undercut the global timeout
MCP connect timeouts now respect the global timeout and get retried instead of failing.
gate cited by this entry, found in this entry's text
-
v2.1.227
MCP connection timeouts are reported as timeouts
A slow MCP server is now reported as a timeout rather than a vague connection failure.
gate cited by this entry, found in this entry's text
Gate readings
8| Release | Resolved | This account | Anonymous | Compiled default |
|---|---|---|---|---|
| v2.1.307 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.301 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.292 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.290 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.288 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.287 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.274 read on another version | Not enough to say | no value returned | no value returned | on |
| v2.1.227 read on another version | Not enough to say | no value returned | no value returned | on |
Two arms, because they disagree: this account is the one account this site reads and anonymous is a baseline with no identity attached. A reading says nothing about your account, and off cannot rule out a rollout both readings sit outside of. What these readings can and cannot show.
First cited
1The earliest release whose published evidence quoted tengu_mcp_connect_timeout_retry was v2.1.227, 10 Aug 2026. That is the oldest release this project wrote about it, so it is a floor on the name's age and not the release that introduced it. It is not a presence reading: which builds carried the name is the table below.
Presence across releases
1Build by build
70One row per release since the first build this name was read out of. Absent means the build was read and the name was not in it, never mined means no bundle for that release was ever archived, and a declared type or a default is only ever what that release's own bundle stated.
Read out of the published npm bundle release by release, and out of Anthropic's own documentation as this site captured it. Nothing on this page is a description anybody here wrote about what the feature flag does. All feature flags.