Issue
The SessionStart hook has a worst-case startup delay of ~30 seconds:
acquire_lock max wait: 15 secondsrun_with_timeout for pull --auto: 15 seconds- Total: 30 seconds (within the 35s outer hooks.json timeout, but barely)
This means if another session holds the lock or the network is slow, every new Claude Code session start is blocked for up to 30 seconds before becoming interactive.
Suggestion
Reduce internal timeouts to provide a snappier experience:
acquire_lock max wait: 5 seconds (if another session is pulling, just skip)run_with_timeout for pull --auto: 10 seconds (enough for a fast git pull, timeout for slow networks)- Total worst case: 15 seconds instead of 30
The 35s outer timeout in hooks.json could also be reduced to 20s for safety headroom.
Trade-off
On very slow networks, a 10s pull timeout might not be enough. But the fallback behavior (skip pull, warn user, continue with cached config) is correct — it's better to start fast with slightly stale config than to block for 30 seconds.
Issue
The SessionStart hook has a worst-case startup delay of ~30 seconds:
acquire_lockmax wait: 15 secondsrun_with_timeoutforpull --auto: 15 secondsThis means if another session holds the lock or the network is slow, every new Claude Code session start is blocked for up to 30 seconds before becoming interactive.
Suggestion
Reduce internal timeouts to provide a snappier experience:
acquire_lockmax wait: 5 seconds (if another session is pulling, just skip)run_with_timeoutforpull --auto: 10 seconds (enough for a fast git pull, timeout for slow networks)The 35s outer timeout in
hooks.jsoncould also be reduced to 20s for safety headroom.Trade-off
On very slow networks, a 10s pull timeout might not be enough. But the fallback behavior (skip pull, warn user, continue with cached config) is correct — it's better to start fast with slightly stale config than to block for 30 seconds.