{"version":"2.1.319","anchor":"project-plugins-in-claudeskills-blocked-after-entering-a-w","canonical_anchor":"project-plugins-in-claudeskills-blocked-after-entering-a-w","heading":"Project plugins in .claude\/skills stop loading after a worktree switch with the sandbox on","tier":"notice","area":"Plugins","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319\/e\/project-plugins-in-claudeskills-blocked-after-entering-a-w","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319","markdown":"### Project plugins in .claude\/skills stop loading after a worktree switch with the sandbox on\n\nIf Claude Code has entered a worktree while the Bash sandbox is or was on, it no longer loads project plugins from .claude\/skills\n\n**What**\n\nClaude Code can load skills from a project's `.claude\/skills` folder as plugins, which are add-ons that extend what it can do. It now refuses to load those project plugins in one situation:\n\n- the running Claude Code has entered a worktree, which is a separate working copy of a git repository, and\n\n- the Bash sandbox, the restricted environment that limits what shell commands can touch, is on now or was on earlier.\n\nWhen this happens, a log message explains that a sandboxed command could have written those plugins, and says to restart Claude Code in the folder that holds the `.claude` folder.\n\n**Why**\n\nThis stops a command that ran inside the sandbox from planting plugins that would then load outside it. The catch is that project plugins can quietly stop loading, so if one goes missing after a worktree switch, restart Claude Code from the project folder.\n\n- Area: Plugins\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}