Claude turns fail in new worktrees: 90s `setMcpServers` limit is shorter than SessionStart hooks#23155

opened3d agobyGggwelson

What happened

Every new Claude thread that T3 Code starts in a fresh worktree of one of my repos fails with:

The provider could not start this turn. Retry the turn; if it keeps failing, check the provider setup and server logs.

The server trace has the real cause:

1	ProviderAdapterTurnStartError: Failed to start run run:thread:<id>:ordinal:1 on claudeAgent provider thread ...
2	[cause]: ClaudeAgentSdkQueryRunnerError: Claude Agent SDK query failed.
3	[cause]: Error: Claude Code did not answer the MCP server registration. (method: setMcpServers)

It started mid-day today and now happens on every new worktree thread. Follow-up turns in existing threads, and threads in the main checkout, still work. I switched from nightly to the stable channel and it still happens. I had to move to the Claude Code CLI to keep working.

Root cause (reproduced)

The repo's .claude/settings.json has a SessionStart hook, matcher startup and "timeout": 600. In a linked worktree, the hook runs the repo's worktree setup script, which installs dependencies, builds types and so on. In the main checkout it exits immediately.

Claude Code doesn't answer the SDK's setMcpServers control request until startup, including SessionStart hooks, has finished. T3 waits for that with a hard-coded limit:

1	const CLAUDE_MCP_REGISTRATION_TIMEOUT = "90 seconds";
2	...
3	queryRuntime.setMcpServers(mcpServers) ... timeoutOrElse({
4	duration: CLAUDE_MCP_REGISTRATION_TIMEOUT,
5	orElse: () => fail(queryRunnerError("Claude Code did not answer the MCP server registration.", "setMcpServers"))
6	})

So whenever a legitimate SessionStart hook takes more than 90 seconds, the turn fails. The user also has no way to tell the cause is a hook.

Reproduction without T3, in a fresh git worktree add --detach of the same repo:

	`claude -p "reply ok"` wall time
main checkout (hook exits immediately)	9s
fresh worktree, first start (hook runs setup)	91s
same worktree, second start (setup cached)	10s

Startup times of ClaudeAgentSdkQueryRunner.open from server.trace.ndjson today:

1	14:14 Success 64968ms <- already near the limit
2	14:54 Success 59128ms
3	15:42 Failure 90002ms
4	15:44 Failure 90003ms
5	15:50 Failure 90003ms
6	15:59 Failure 90003ms
7	16:02 Success 3054ms (non-worktree thread)
8	16:08 Failure 90002ms

My guess about why it started today: dependency manifest changes pulled mid-day invalidated the setup script's cached install, so first-start setup went from about 60s to more than 90s. The 90s limit was already marginal for this repo.

T3 shows no "Setting up worktree" hook status, so all the user sees is a long spinner and then a generic provider error.

Expected

One or more of:

Don't apply a 90s limit to setMcpServers while Claude Code is still running SessionStart hooks. Respect the hook's configured timeout, or make the limit configurable.
Show hook progress or statusMessage while the provider starts, so it doesn't look like a hang.
When it does time out, say that Claude Code was still starting up (for example, running SessionStart hooks) instead of showing the generic "provider could not start this turn".

#22198: same CLAUDE_MCP_REGISTRATION_TIMEOUT failure with a different trigger (hung OpenCode subagent), plus the stuck-thread recovery problem it can cause.
#20828 / #21608: the generic error hides the underlying cause.
#14244: no "starting agent" state while the provider starts.

Workarounds

Start the thread in the main checkout or in an already-set-up worktree.
Run the repo's setup as a T3 project setup script so the hook finds a warm cache. (Not verified.)

Environment

T3 Code (Beta) desktop 0.1.1, stable channel (also seen on nightly earlier today)
macOS 27.0.1, Apple Silicon
Claude Code CLI 2.1.306 → 2.1.307 (failed on both)
Provider: claudeAgent, claude-opus-5-5

JJulius Marminge3d ago

Reproduced on main b5a226e49c, Linux x64, web dev client, Claude Code 2.1.303 / Opus 5.5, isolated state. A fixture repository uses a SessionStart / startup command hook with timeout: 600; its main checkout exits immediately and a fresh linked worktree takes 105 seconds.

Sending reply ok in the app succeeds in the main checkout. The fresh-worktree turn fails in ClaudeAgentSdkQueryRunner.open at 90,209 ms with Claude Code did not answer the MCP server registration. while the hook is still running. Direct CLI in the main checkout succeeds in 12.7 seconds. The reporter’s private setup script and macOS desktop were not tested.

cold-worktree-failed.png cold-worktree-timeout.mp4 runtime-before.json

Gggwelson2d ago

Stopgap that works today (verified), for anyone blocked on this until #23202 ships

Configure a blocking project setup script in T3 Code that runs the same setup your SessionStart hook runs. T3 waits for a runOnWorktreeCreate script with async: false without any timeout before it starts the agent, so by the time Claude's hook runs, the install is cached and the hook finishes in a few seconds — well under the 90s setMcpServers deadline.

In my case (repo hook = .agents/scripts/setup-worktree.sh, cold worktree ≈ 60s bun install + type generation):

	Before	With blocking setup script
T3 setup stage	—	~105s, awaited, no limit
SessionStart hook	65–90s (full install)	5.0s (install skipped, cached)
`ClaudeAdapterV2.startTurn`	66s, or 90s timeout	5.9s

How to set it:

UI: project sidebar → "Add project script" → command = your setup script, enable Run on worktree create, and make it blocking (async: false; the default is async, which does not help because the agent starts while the script is still running).
Or settings file: ~/.t3/userdata/settings.json (the server fs-watches it, no restart needed):

json

1	"projectSettingsOverrides": {
2	"<projectId>": {
3	"defaultProjectScripts": [{
4	"id": "worktree-setup",
5	"name": "Worktree setup (blocking)",
6	"command": "./.agents/scripts/setup-worktree.sh",
7	"icon": "configure",
8	"runOnWorktreeCreate": true,
9	"async": false
10	}]
11	}
12	}

One gotcha that cost me a round-trip: with projectSettingsFolded: true (the current default), resolveProjectScripts only reads projectSettingsOverrides[projectId].defaultProjectScripts (or the environment default) and ignores the project's legacy scripts field — so setting scripts via t3_project_update from an agent has no effect. Use the UI or the override above.

Side benefits: setup progress shows as a stage in the thread, and a failing setup produces "Setup script exited with N" instead of the generic provider error. I'll keep it even after the timeout fix lands.

Dderickdsouza1d ago

Another trigger for the same 90 s setMcpServers limit: no repo hook, but a large global Claude Code config on a loaded machine.

T3 Code Nightly 0.1.3-nightly.20261023.3566, macOS arm64, Claude Code with Opus 5.5.
Scheduled tasks (2 min interval), each run in a fresh worktree. The repo has no .claude/ hooks.

ClaudeAgentSdkQueryRunner.open from server.trace.ndjson, 15:41 to 17:02 local time:

Result	Count	Duration
Success	5	33 s to 77 s
Failure	12	90.0 s each, `Claude Code did not answer the MCP server registration.`

claude -p time to the init message, same user config:

Config	Time to init
Full: 44 MCP servers (11 connected, 10 failed, 23 needs-auth), 131 plugins	48.5 s
`--strict-mcp-config`	12.3 s

Load average was about 250 on 16 cores at the time, so a 48 s start can pass 90 s. Please check that #23202 also covers slow MCP connection and slow machines, not only slow SessionStart hooks.

Wwalde-dev1d ago

Another trigger for the same 90 s setMcpServers limit: memory pressure in the agent slice from one runaway agent child. There's no slow hook and no fresh worktree involved.

Environment

Server: T3 Code 0.1.3-nightly.20261023.3566, background service (systemd user unit), Linux x64 (Ubuntu on WSL2), 32 GB RAM, 8 GB swap
Client: desktop app Nightly 0.1.3-nightly.20261023.3566 on macOS arm64, connected to that remote server
Claude Code 2.1.309, Opus 5.5

What happened

A long-running thread had its Claude process idle-closed hours earlier, so the next turn needed a fresh claude --resume launch. That turn, and the retry, both failed after about 90 s with "The provider could not start this turn". The trace shows the same cause as in this issue:

1	ClaudeAdapterV2.startTurn 90071 ms Failure
2	ClaudeAgentSdkQueryRunner.open 90037 ms
3	[cause]: Error: Claude Code did not answer the MCP server registration.

ClaudeAgentSdkQueryRunner.open outcomes on that server:

Time (UTC)	Duration	Result
13:28 to 13:35, 5 opens	0.5 to 0.7 s	Success
13:39:07	90 095 ms	Failure
13:41:49	90 037 ms	Failure
13:43:34	90 066 ms	Failure

Turns in threads whose Claude process was already running kept working the whole time, which made it look thread-specific.

Cause

Around 13:30 an agent in another thread ran a railway up deploy. That process grew to about 21 GB RSS and stayed there. It ran inside that thread's t3code-claude-*.scope, under app-t3code-agents.slice:

1	app-t3code-agents.slice MemoryCurrent=27.56 GB MemoryHigh=27.21 GB MemoryMax=29.36 GB
2	memory.events: high 932049, max 0, oom 0, oom_kill 0
3	Swap: 8192 / 8192 MB used

The slice sat above MemoryHigh without ever reaching MemoryMax, so the kernel throttled every process in it and no OOM kill ever fired. Already-running Claude processes stayed slow but usable. A freshly spawned CLI (about 290 MB resident) couldn't get through startup within 90 s, so setMcpServers timed out every time. Nothing in the UI or the error points at memory pressure or at the other thread's child process.

What would have helped

The fix in #23202 (not tying session survival to a fixed 90 s registration window) would likely cover this too.
When a Claude start times out, surface agent-slice pressure (memory.events high growing, or MemoryCurrent > MemoryHigh) in the error, plus the largest process in the slice and which thread owns it. Here the culprit was one process in another thread's scope.
This is related to #18350 (closed): MemoryHigh stalls without an OOM kill.

Diagnosed and written by Claude Opus 5.5 (Claude Code) via t3 triage.