VS Code extension: the 60 s subprocess initialisation limit is hard-coded and counts SessionStart hooks the CLI itself allows 600 s for

Environment

• Windows 11 Pro
• Git for Windows (Git Bash)
• Claude Code 2.1.269
• VS Code extension 2.1.269
• A third-party plugin installed from the marketplace with a SessionStart hook (remember, 0.30.0)

What Happens

The VS Code extension gives the Claude Code subprocess a hard-coded 60,000 ms to finish initialising (extension.js: Q=60000). There's no setting and no environment variable to change it, and it isn't documented. When a SessionStart hook runs longer than that, the session fails with:

Subprocess initialization did not complete within 60000ms - check authentication and network connectivity

This is misleading. In our case, neither authentication nor network connectivity was the cause. A SessionStart hook was simply still running.

Separately, Claude Code's own documented default timeout for a SessionStart hook is 600 s (hooks guide, Limitations). A hook the CLI itself is willing to wait ten minutes for can kill a VS Code session at one minute.

Measurements

On the same machine, with a real, populated memory-plugin store, a SessionStart hook took:

| Condition | Time |
|---|---|
| Fresh store | 0.3-2 s |
| Quiet machine | 23.5 s |
| Under load (3 worker sessions + 1 QA session) | 188.3 s |

A headless claude -p start from the same folder took 44.0 s before we fixed an unrelated marketplace-naming defect, ours, and 29.2 s after. The SessionStart hook is the remaining bulk. All of this sits well past the extension's 60 s limit under anything but the quiet case.

Expected

One of:

• The 60 s limit is configurable (a setting, or a CLAUDE_CODE_* environment variable), or
• Time spent in SessionStart hooks is excluded from the subprocess-initialisation budget (since the CLI already grants hooks their own much longer timeout), or
• The error message names the hook that was still running, instead of pointing at authentication/network

Suggested Change

Our preference is the second option. Exclude hook execution time from the 60 s subprocess-initialisation window, since the CLI already allows a SessionStart hook up to 600 s. Either of the other two options would also resolve the misleading error.

Note

We're separately raising the slowness of our specific SessionStart hook with that plugin's maintainer (claude-remember#660). This issue is about the extension's hard-coded limit and its misleading error, independent of any one plugin's hook performance.

JQiT Pty Ltd