[BUG] Native plugin manager in the VS Code extension doesn't work with claudeProcessWrapper set

Resolved 💬 3 comments Opened Jan 28, 2026 by justin39 Closed Mar 1, 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?

When claudeCode.claudeProcessWrapper is set, running /plugins from inside the extension window to bring up the new native plugin manager results in an error like Failed to load plugins: Claude CLI exited with code 1: [...] error: unknown option '--json'.

This appears to be because the extension is passing the full path to the bundled Claude binary as an argument to the wrapper script. For example, if I ask the wrapper script to log the contents of $@ to a file, I see:

/home/user/.vscode-server/extensions/anthropic.claude-code-2.1.22-linux-x64/resources/native-binary/claude plugin list --json

instead of plugin list --json, which is what I would expect to receive as arguments to the wrapper script.

What Should Happen?

/plugins should load the new native plugin manager interface, even when claudeProcessWrapper is set.

Error Messages/Logs

Steps to Reproduce

  1. Create a wrapper script and point claudeCode.claudeProcessWrapper at it:
#!/bin/bash
/path/to/node /path/to/cli.js "$@"
  1. Run the /plugins slash command from the VS Code extension panel

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.15

Claude Code Version

2.1.22

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

This was tested via a VS Code server instance started by code serve-web.

We've worked around this by adding the following check to our wrapper:

if [[ "${1:-}" == */.vscode-server/extensions/anthropic.claude-code-*/resources/native-binary/claude ]]; then
    shift
fi

This seems to fix the issue, as the native plugin manager interface works after adding this check, which lends credence to the theory above that the wrapper is receiving an extraneous path as the first argument.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗