VSCode extension: 'Loading config cache by launching Claude' pre-launch takes 11-51s on ARM64/LinuxKit, blocks session-ready

Summary

On ARM64 LinuxKit hosts (GitHub Codespaces, Docker Desktop on Mac devcontainers), the VS Code extension's pre-spawn step Loading config cache by launching Claude (no channel)... takes 11–51 seconds before the user-visible Spawning Claude with SDK query function fires. The 45-second outliers correlate with ~/.claude/settings.json having changed since the previous session (cache invalidation forces a full native-binary cold start).

Same operation completes in ~14 ms when the cache is warm.

Environment

• VS Code Insiders, extension Anthropic.claude-code v2.1.139
• Native binary: ~/.vscode-server-insiders/extensions/anthropic.claude-code-2.1.139-linux-arm64/resources/native-binary/claude
• Host: GitHub Codespaces devcontainer, ARM64, LinuxKit kernel, linux/arm64 runtime
• Settings.json contains 12 OTEL_* env vars + 294 Bash(...) allowlist entries (~25 KB total). No exotic hooks; only the documented hooks.json schema.

Evidence (from extension log)

Fast session (warm cache):

2026-05-12 05:15:34.335 Loading config cache by launching Claude (no channel)...
2026-05-12 05:15:34.349 Spawning Claude with SDK query function ... version: 2.1.139

→ 14 ms, cache hit.

Slow session (cache invalidated by a prior settings.json write):

2026-05-12 16:44:53.446 AuthManager initialized
2026-05-12 16:44:58.878 Loading config cache by launching Claude (no channel)...
[45.2-second silent gap]
2026-05-12 16:45:44.081 (first webview interactivity)
2026-05-12 16:45:49.929 Spawning Claude with SDK query function ... version: 2.1.139

→ 51 seconds from "Loading config cache" to "Spawning Claude". Total extension-to-ready: 56.5 seconds.

Yesterday's same operation on the same machine (cold but recent settings.json untouched): 11.6 seconds. So the variance is [11–51]s and it correlates with whether ~/.claude/settings.json was recently modified.

Reproducer

1. GitHub Codespace OR Docker Desktop devcontainer on Apple Silicon (ARM64).
2. With extension running, edit ~/.claude/settings.json (any change — jq '.env.FOO = "bar"' ... > ... works).
3. Close and reopen the VS Code window pointing at any workspace.
4. Measure elapsed time from AuthManager initialized to Spawning Claude with SDK query function in ~/.vscode-server*/data/logs/<timestamp>/exthost*/Anthropic.claude-code/Claude VSCode.log.

Expected (warm): <1 s for the "Loading config cache" step.
Actual (cache invalidated by recent settings.json change): 11–51 s.

Why this matters for us

CloudIngenium's internal Knowledge-Hub repo runs a pnpm run sync that legitimately writes ~/.claude/settings.json (env vars, allowlist, plugin enablement) on every fleet-wide sync. Each sync invalidates this cache, so the next opened VS Code session pays the cold pre-launch.

Suggested fixes (ordered by ease)

1. Make pre-launch fully async / non-blocking — emit Spawning Claude with SDK query function immediately; let the config cache rebuild concurrently in the background. The cache hit, when it eventually lands, would simply update an in-memory pointer. This is the change with the largest impact and likely no behavioral regression (worst case the FIRST user prompt waits a bit longer for the cache, but session-open feels instant).

1. Skip the pre-launch when cache file is recent — if ~/.claude/cache/... is younger than, say, 1 hour AND its source dependencies (settings.json mtime, extension version) haven't changed in that window, treat the cache as valid and skip the warm-up subprocess entirely.

1. Provide an opt-out env var — CLAUDE_CODE_SKIP_CONFIG_CACHE_PRELAUNCH=1 so platforms where the cold cost outweighs the benefit (ARM64 LinuxKit devcontainers, headless servers) can disable it.

1. Quicker native-binary cold start on ARM64 Bun — orthogonal to this issue but related: a 45-second cold start for a Bun binary is unusual; some of that may be FS-cache-cold disk I/O specific to LinuxKit's overlay FS. A precompiled snapshot or AOT hint might help.

Happy to test any of the above against this Codespace if useful.

cc: (no specific contributors; filing as a generic perf bug)