You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(core): V1 to V2 MCP migration drops timeout.startup, so scalar timeouts never reach the connect budget #54184
The V1 to V2 MCP config migration drops a per-server scalar timeout on the startup budget, which is the only budget that governs the MCP connection handshake.
A local MCP server still bearing its V1 shape has timeout as a plain integer. In V1 that integer applied to the handshake as well as tool calls. After migration it only reaches catalog and execution, so connection keeps using the built-in default no matter what the user set.
Reproduction
Normalize a config that still carries a legacy per-server integer timeout:
Because the built-in startup default is also 30000, the regression is invisible for the common timeout: 30000 case. It becomes visible for any differing value: a 5000 scalar gives a 5s tool-call budget while connection still gets the 30s default.
Environment
opencode v2.0.26, and the same mapping is present at origin/v2 HEAD
Windows 10 Pro 10.0.19045 x64
bun 1.4.2
Impact
Anyone who migrated a V1 mcp.<server>.timeout scalar to V2 lost control of the MCP connection budget. Raising it no longer grants a slow server more time to connect; lowering it no longer fails fast at connection time. This restores the V1 behaviour for a field people were already setting.
Thanks for the detailed report. I reproduced this on 2.0.26 with a local stdio MCP server that waits 12s before answering initialize:
With the V1-style "timeout": 5000, opencode debug config shows the normalized value as {"catalog":5000,"execution":5000}, with no startup. opencode mcp list then reports the server as connected after about 12s, so the 30s default startup budget applied instead of 5s.
With the V2 form "timeout": { "startup": 5000 } under mcp.servers, the same server fails with Request timed out after about 5s, as expected.
On the latest v2 (229b422), ConfigNormalize.normalize still produces { catalog, execution } without startup for the same input. The mapping comes from migrateMcp in packages/core/src/v1/config/migrate.ts. V1 did use the per-server timeout as the connect timeout, so this is a regression from the migration. The script below reproduces it end to end.
Until it's fixed, you can work around it by writing the V2 form explicitly, mcp.servers.<name>.timeout: { startup, catalog, execution }.
Activity
opencode-agent commentedon Oct 9, 2026
Thanks for the detailed report. I reproduced this on 2.0.26 with a local stdio MCP server that waits 12s before answering
initialize:"timeout": 5000,opencode debug configshows the normalized value as{"catalog":5000,"execution":5000}, with nostartup.opencode mcp listthen reports the server asconnectedafter about 12s, so the 30s default startup budget applied instead of 5s."timeout": { "startup": 5000 }undermcp.servers, the same server fails withRequest timed outafter about 5s, as expected.On the latest
v2(229b422),ConfigNormalize.normalizestill produces{ catalog, execution }withoutstartupfor the same input. The mapping comes frommigrateMcpinpackages/core/src/v1/config/migrate.ts. V1 did use the per-servertimeoutas the connect timeout, so this is a regression from the migration. The script below reproduces it end to end.Until it's fixed, you can work around it by writing the V2 form explicitly,
mcp.servers.<name>.timeout: { startup, catalog, execution }.Related:
startupto the migrated timeouttimeoutfield dropped during normalization (a different problem)Reproduction script (repro.sh)
Run it:
bash repro.sh