›_ Claude Code Issues
Claude Code Issues / #88991

[BUG] Plugin marketplace auto-update runs synchronously inside PreToolUse hook path, causing multi-minute session hangs under concurrent sessions (Windows)

Status Open
Reported on v2.1.241
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Aug 23, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Title

Plugin marketplace auto-update runs synchronously inside PreToolUse hook path, causing multi-minute session hangs under concurrent sessions (Windows)

Environment

  • Claude Code VSCode extension version: 2.1.241 (also seen on 2.1.240)
  • OS: Windows 11 Home 10.0.26200
  • Install: native, extension at anthropic.claude-code-2.1.241-win32-x64
  • Multiple chat sessions/tabs open concurrently in the same VSCode window (6 in the reproducing case)

Summary

When a plugin marketplace has autoUpdate enabled, the extension's PreToolUse hook path triggers a synchronous git clone of the plugin repo into the shared plugin cache directory (~/.claude/plugins/cache/<marketplace>/...) as part of dispatching an unrelated tool call (observed on Edit). If another concurrently-running Claude Code session already holds a handle on that same cache path, the clone/cleanup step fails with EBUSY: resource busy or locked on Windows, and the extension retries — blocking the entire tool call, and by extension the whole chat session, for several minutes. The UI shows the session as "working" (spinner) with no indication anything is wrong.

Evidence (from %APPDATA%\Code\logs\<session>\window*\exthost\Anthropic.claude-code\Claude VSCode.log)

[DEBUG] Cache for playwright@claude-plugins-official at ...\cache\claude-plugins-official\playwright\unknown is in use by another session; deferring overwrite until it exits
[DEBUG] Updated playwright@claude-plugins-official on disk to version unknown
[INFO] Slow PreToolUse hooks: 2714ms for Edit (7 hooks)
[DEBUG] Cloned repository from https://github.com/obra/superpowers.git to ...\temp_git_1787491717656_pfc23y
[WARN] Plugin autoupdate: error updating superpowers@claude-plugins-official: EBUSY: resource busy or locked, rm '...\temp_git_1787491717656_pfc23y'
[DEBUG] Caching plugin from source: ... to temporary path ...\temp_git_1787491720816_1m9w00

Immediately after, the webview reported:

{"type":"log_event","eventName":"input_lag_sample","eventData":{"durationMs":392912}}

— 392,912ms (6.5 minutes) of input lag on that channel, followed by the user closing the unresponsive tab.

A second channel in the same window, launched around the same time, was closed ~22 seconds after launch with no intervening activity logged at all — consistent with the same plugin-cache lock contention blocking startup.

Earlier occurrences also show, at extension startup with multiple sessions racing:

[DEBUG] Lock acquisition took longer than expected - another Claude instance may be running

repeated 5-6 times within 20 seconds during one cold start.

Root cause (as far as can be determined from logs)

  1. Plugin auto-update is wired into the PreToolUse hook execution path, not run out-of-band.
  2. It performs a network git clone + directory rm/rename against a cache path shared by every concurrently running Claude Code session (per-user, not per-session).
  3. On Windows, a directory handle held open by one process causes EBUSY on another process's delete/rename of the same path (POSIX rm semantics don't apply) — the retry loop then blocks the calling tool call/hook for as long as retries take.
  4. Nothing in the UI communicates that the hang is plugin-update-related; it just looks like the assistant is silently "thinking."

Repro

  1. Open a VSCode window with 2+ concurrent Claude Code chat sessions.
  2. Ensure at least one enabled plugin's marketplace has autoUpdate: true (or is on a default that behaves as auto-updating), e.g. claude-plugins-official.
  3. Trigger tool calls (e.g. Edit) in multiple sessions around the same time, ideally shortly after a new session cold-start (which itself kicks off a marketplace refresh).
  4. Observe one or more sessions stall for multiple minutes with no visible error, while Claude VSCode.log shows EBUSY / "in use by another session" / repeated git-clone retries.

Suggested fix

  • Do not run plugin marketplace update (network clone + cache rewrite) synchronously inside the PreToolUse hook path; move it to a background/idle-time task that never blocks tool dispatch.
  • Serialize/lock plugin-cache updates across concurrent sessions with a proper mutex (or skip the update entirely if another session is already updating) instead of retrying into EBUSY.
  • Surface a visible status (e.g. "updating plugin X…") instead of a silent hang when this does take time.

Workaround (in the meantime)

Set "autoUpdate": false explicitly for every entry under extraKnownMarketplaces in ~/.claude/settings.json, including claude-plugins-official (it has no default autoUpdate key and was still auto-updating despite the global "autoUpdates": false in ~/.claude.json).

What Should Happen?

Title

Plugin marketplace auto-update runs synchronously inside PreToolUse hook path, causing multi-minute session hangs under concurrent sessions (Windows)

Environment

  • Claude Code VSCode extension version: 2.1.241 (also seen on 2.1.240)
  • OS: Windows 11 Home 10.0.26200
  • Install: native, extension at anthropic.claude-code-2.1.241-win32-x64
  • Multiple chat sessions/tabs open concurrently in the same VSCode window (6 in the reproducing case)

Summary

When a plugin marketplace has autoUpdate enabled, the extension's PreToolUse hook path triggers a synchronous git clone of the plugin repo into the shared plugin cache directory (~/.claude/plugins/cache/<marketplace>/...) as part of dispatching an unrelated tool call (observed on Edit). If another concurrently-running Claude Code session already holds a handle on that same cache path, the clone/cleanup step fails with EBUSY: resource busy or locked on Windows, and the extension retries — blocking the entire tool call, and by extension the whole chat session, for several minutes. The UI shows the session as "working" (spinner) with no indication anything is wrong.

Evidence (from %APPDATA%\Code\logs\<session>\window*\exthost\Anthropic.claude-code\Claude VSCode.log)

[DEBUG] Cache for playwright@claude-plugins-official at ...\cache\claude-plugins-official\playwright\unknown is in use by another session; deferring overwrite until it exits
[DEBUG] Updated playwright@claude-plugins-official on disk to version unknown
[INFO] Slow PreToolUse hooks: 2714ms for Edit (7 hooks)
[DEBUG] Cloned repository from https://github.com/obra/superpowers.git to ...\temp_git_1787491717656_pfc23y
[WARN] Plugin autoupdate: error updating superpowers@claude-plugins-official: EBUSY: resource busy or locked, rm '...\temp_git_1787491717656_pfc23y'
[DEBUG] Caching plugin from source: ... to temporary path ...\temp_git_1787491720816_1m9w00

Immediately after, the webview reported:

{"type":"log_event","eventName":"input_lag_sample","eventData":{"durationMs":392912}}

— 392,912ms (6.5 minutes) of input lag on that channel, followed by the user closing the unresponsive tab.

A second channel in the same window, launched around the same time, was closed ~22 seconds after launch with no intervening activity logged at all — consistent with the same plugin-cache lock contention blocking startup.

Earlier occurrences also show, at extension startup with multiple sessions racing:

[DEBUG] Lock acquisition took longer than expected - another Claude instance may be running

repeated 5-6 times within 20 seconds during one cold start.

Root cause (as far as can be determined from logs)

  1. Plugin auto-update is wired into the PreToolUse hook execution path, not run out-of-band.
  2. It performs a network git clone + directory rm/rename against a cache path shared by every concurrently running Claude Code session (per-user, not per-session).
  3. On Windows, a directory handle held open by one process causes EBUSY on another process's delete/rename of the same path (POSIX rm semantics don't apply) — the retry loop then blocks the calling tool call/hook for as long as retries take.
  4. Nothing in the UI communicates that the hang is plugin-update-related; it just looks like the assistant is silently "thinking."

Repro

  1. Open a VSCode window with 2+ concurrent Claude Code chat sessions.
  2. Ensure at least one enabled plugin's marketplace has autoUpdate: true (or is on a default that behaves as auto-updating), e.g. claude-plugins-official.
  3. Trigger tool calls (e.g. Edit) in multiple sessions around the same time, ideally shortly after a new session cold-start (which itself kicks off a marketplace refresh).
  4. Observe one or more sessions stall for multiple minutes with no visible error, while Claude VSCode.log shows EBUSY / "in use by another session" / repeated git-clone retries.

Suggested fix

  • Do not run plugin marketplace update (network clone + cache rewrite) synchronously inside the PreToolUse hook path; move it to a background/idle-time task that never blocks tool dispatch.
  • Serialize/lock plugin-cache updates across concurrent sessions with a proper mutex (or skip the update entirely if another session is already updating) instead of retrying into EBUSY.
  • Surface a visible status (e.g. "updating plugin X…") instead of a silent hang when this does take time.

Workaround (in the meantime)

Set "autoUpdate": false explicitly for every entry under extraKnownMarketplaces in ~/.claude/settings.json, including claude-plugins-official (it has no default autoUpdate key and was still auto-updating despite the global "autoUpdates": false in ~/.claude.json).

Error Messages/Logs

Steps to Reproduce

Title

Plugin marketplace auto-update runs synchronously inside PreToolUse hook path, causing multi-minute session hangs under concurrent sessions (Windows)

Environment

  • Claude Code VSCode extension version: 2.1.241 (also seen on 2.1.240)
  • OS: Windows 11 Home 10.0.26200
  • Install: native, extension at anthropic.claude-code-2.1.241-win32-x64
  • Multiple chat sessions/tabs open concurrently in the same VSCode window (6 in the reproducing case)

Summary

When a plugin marketplace has autoUpdate enabled, the extension's PreToolUse hook path triggers a synchronous git clone of the plugin repo into the shared plugin cache directory (~/.claude/plugins/cache/<marketplace>/...) as part of dispatching an unrelated tool call (observed on Edit). If another concurrently-running Claude Code session already holds a handle on that same cache path, the clone/cleanup step fails with EBUSY: resource busy or locked on Windows, and the extension retries — blocking the entire tool call, and by extension the whole chat session, for several minutes. The UI shows the session as "working" (spinner) with no indication anything is wrong.

Evidence (from %APPDATA%\Code\logs\<session>\window*\exthost\Anthropic.claude-code\Claude VSCode.log)

[DEBUG] Cache for playwright@claude-plugins-official at ...\cache\claude-plugins-official\playwright\unknown is in use by another session; deferring overwrite until it exits
[DEBUG] Updated playwright@claude-plugins-official on disk to version unknown
[INFO] Slow PreToolUse hooks: 2714ms for Edit (7 hooks)
[DEBUG] Cloned repository from https://github.com/obra/superpowers.git to ...\temp_git_1787491717656_pfc23y
[WARN] Plugin autoupdate: error updating superpowers@claude-plugins-official: EBUSY: resource busy or locked, rm '...\temp_git_1787491717656_pfc23y'
[DEBUG] Caching plugin from source: ... to temporary path ...\temp_git_1787491720816_1m9w00

Immediately after, the webview reported:

{"type":"log_event","eventName":"input_lag_sample","eventData":{"durationMs":392912}}

— 392,912ms (6.5 minutes) of input lag on that channel, followed by the user closing the unresponsive tab.

A second channel in the same window, launched around the same time, was closed ~22 seconds after launch with no intervening activity logged at all — consistent with the same plugin-cache lock contention blocking startup.

Earlier occurrences also show, at extension startup with multiple sessions racing:

[DEBUG] Lock acquisition took longer than expected - another Claude instance may be running

repeated 5-6 times within 20 seconds during one cold start.

Root cause (as far as can be determined from logs)

  1. Plugin auto-update is wired into the PreToolUse hook execution path, not run out-of-band.
  2. It performs a network git clone + directory rm/rename against a cache path shared by every concurrently running Claude Code session (per-user, not per-session).
  3. On Windows, a directory handle held open by one process causes EBUSY on another process's delete/rename of the same path (POSIX rm semantics don't apply) — the retry loop then blocks the calling tool call/hook for as long as retries take.
  4. Nothing in the UI communicates that the hang is plugin-update-related; it just looks like the assistant is silently "thinking."

Repro

  1. Open a VSCode window with 2+ concurrent Claude Code chat sessions.
  2. Ensure at least one enabled plugin's marketplace has autoUpdate: true (or is on a default that behaves as auto-updating), e.g. claude-plugins-official.
  3. Trigger tool calls (e.g. Edit) in multiple sessions around the same time, ideally shortly after a new session cold-start (which itself kicks off a marketplace refresh).
  4. Observe one or more sessions stall for multiple minutes with no visible error, while Claude VSCode.log shows EBUSY / "in use by another session" / repeated git-clone retries.

Suggested fix

  • Do not run plugin marketplace update (network clone + cache rewrite) synchronously inside the PreToolUse hook path; move it to a background/idle-time task that never blocks tool dispatch.
  • Serialize/lock plugin-cache updates across concurrent sessions with a proper mutex (or skip the update entirely if another session is already updating) instead of retrying into EBUSY.
  • Surface a visible status (e.g. "updating plugin X…") instead of a silent hang when this does take time.

Workaround (in the meantime)

Set "autoUpdate": false explicitly for every entry under extraKnownMarketplaces in ~/.claude/settings.json, including claude-plugins-official (it has no default autoUpdate key and was still auto-updating despite the global "autoUpdates": false in ~/.claude.json).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

## Environment - Claude Code VSCode extension version: 2.1.241 (also seen on 2.1.240) - OS: Windows 11 Home 10.0.26200 - Install: native, extension at anthropic.claude-code-2.1.241-win32-x64 - Multiple chat sessions/tabs open concurrently in the same VSCode window (6 in the reproducing case)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Installation & update problems, IDE & terminal integration, Hooks & automation, Windows & WSL problems, Crashes, hangs & freezes

Browse all Claude Code issue topics →