SessionStart hook averages ~12.5s on Windows (Git Bash) — measured over 36 session starts on v0.29.1

[blakeh8]

Summary

On Windows (Git Bash hooks), session-start-hook.sh averages ~12.5 s per session start — measured across 36 real session starts over 14 days on v0.29.1. This is steady-state latency, not the intermittent consolidation block from #646: it's paid on essentially every start.

Measurements

Taken from Claude Code's own transcript hook records (durationMs on hook attachments), aggregated across all sessions in the window:

Hook	n	avg	max
session-start-hook.sh (SessionStart)	36	12,491 ms	114,379 ms
user-prompt-hook.sh (UserPromptSubmit)	502	1,046 ms	7,107 ms

For contrast, other SessionStart hooks in the same sessions (plain bash scripts, similar size) average 0.5–1.3 s, so this isn't generic shell overhead — though Windows process-spawn cost is a plausible multiplier (each subprocess/jq invocation under Git Bash costs ~50–200 ms, so a hook that shells out dozens of times pays for it roughly 10× harder than on Unix).

Caveats stated honestly:

• The 114 s max may be the SessionStart hook blocks ~99s on consolidation, exceeding the VS Code extension's 60s subprocess-init timeout #646 consolidation path or a laptop suspend/resume inflating wall-clock time — I'm not leaning on it. The 12.5 s average across 36 starts is the report.
• One non-blocking failure in the window: session-start-hook: ERROR -- failed to source <plugin>/scripts/log.sh (single occurrence, didn't recur).

Environment

• Plugin: remember v0.29.1 via the claude-plugins-official marketplace (pinned sha 1f5d3f9)
• Claude Code 2.1.268, native install
• Windows 11 (ARM64), hooks executed under Git Bash
• Heavily used install (the plugin works well — this is purely about start latency)

Ask

Whatever the fix shape is — fewer subprocess invocations on the hot path, batching the jq reads, or pushing more of the start work into the backgrounded phase the #646 fix established — a Windows-representative timing budget for the foreground portion of session start would be the win. Happy to run instrumented builds or provide more granular timings from this machine if useful.

---

Measured and drafted with Claude Code session diagnostics; posted by the account owner.

[fdaviddpt]

Fewer jq forks on the promo path landed in #661 (10 -> 4 per session start, measured on macOS). It does not close this issue -- that reduction is one part of the hook's foreground path, not the whole ~12.5s average this issue measured, so #660 stays open pending a Windows-representative re-measure.

@blakeh8 if you're up for it, a re-measure on the next release (once the star-ask/promo change from #661 ships) would help confirm whether the promo path was actually the bulk of the hot-path cost on Git Bash, or whether there's more to account for elsewhere in the hook.

[AI-generated]

[jqit-ricky]

We measured the SessionStart hook against a real, populated memory store. Environment: Windows 11 (Git for Windows), Claude Code 2.1.269, VS Code extension 2.1.269, remember plugin 0.30.0 from the marketplace.

Condition	Time	stdout	Forked commands
Fresh store	0.3-2 s	-	-
Quiet machine	23.5 s	~455 KB	~1,400
Under load (3 workers + 1 QA session)	188.3 s	~455 KB	~1,400

Exit code was 0 every time. We traced the hook with PS4='+$EPOCHREALTIME ' bash -x: about 1,400 forked commands per run. On this machine a Git Bash fork costs 90 ms idle, 263 ms under load (normal is 10-30 ms). Fork count drives most of the wall-clock time, and it gets worse exactly when the machine is busiest. The single largest gap was a 6.95 s wait inside the before_session_start dispatch (hooks.d/before_session_start/50-git-restore.sh). That step's own header budgets only 0.17-0.22 s for itself.

This collides with the VS Code extension's hard-coded 60,000 ms subprocess initialisation limit (see #646), which has no setting or variable to raise it. Under load, this hook alone exceeds that limit threefold. The resulting error is Subprocess initialization did not complete within 60000ms - check authentication and network connectivity, which misleadingly points at authentication or network rather than the hook's own runtime.

One concrete suggestion: declare the SessionStart hook "async": true in hooks.json. The CLI already supports async hooks on SessionStart. Claude Code's own default SessionStart timeout is 600 s, ten times the extension's budget, so long runs are already expected (hooks guide, Limitations). Async would let memory context arrive on the first turn instead of blocking initialisation.

If async isn't preferred, a smaller fallback exists. Stop awaiting the before_session_start dispatch, or at least 50-git-restore.sh, in the foreground. That step is where the largest single delay sits relative to its own stated budget.

Happy to share the full trace if useful.

JQiT Pty Ltd