# Claude turns fail in new worktrees: 90s \`setMcpServers\` limit is shorter than SessionStart hooks · Issue \#23155 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/23155)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/23155)

---

### 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:

```
ProviderAdapterTurnStartError: Failed to start run run:thread:<id>:ordinal:1 on claudeAgent provider thread ...
  [cause]: ClaudeAgentSdkQueryRunnerError: Claude Agent SDK query failed.
    [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:

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

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:

```
14:14 Success 64968ms   <- already near the limit
14:54 Success 59128ms
15:42 Failure 90002ms
15:44 Failure 90003ms
15:50 Failure 90003ms
15:59 Failure 90003ms
16:02 Success  3054ms   (non-worktree thread)
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".

### Related

- #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