[waldekmastykarz]

Closes #2056

Adds a devproxy plugin list command that lists the plugins available in a plugin assembly, so users and agents don't have to resort to reflection or scanning DLL bytes to discover plugin names.

devproxy plugin list                                # built-in plugins
devproxy plugin list --output json                  # machine-readable
devproxy plugin list --plugin-path ./MyPlugins.dll  # custom plugin assembly

Sample output:

Plugins in /…/plugins/DevProxy.Plugins.dll:

  ApiCenterMinimalPermissionsPlugin (configurable)
  ...
  RetryAfterPlugin
  ...

To use a plugin, add it to the plugins array in your config with "name": "<plugin name>" and "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll".

JSON output returns name, pluginPath (ready to paste into config) and isConfigurable for each plugin.

Notes

• The command runs standalone (handled early in Program.cs, like config validate), so it works without a valid config file and doesn't load configured plugins. Without this, any command fails when the config has issues, which is exactly when you'd want to look up plugin names.
• It's still registered on the root command so it shows up in devproxy --help.
• Plugin discovery matches the runtime loader: public, non-abstract types implementing IPlugin, loaded via PluginLoadContext. IsConfigurablePlugin was made internal to reuse it.
• Updated the plugin catalog skill reference to mention the command.

[Copilot]

🟡 Changes recommended

Plugin listing has unresolved path-resolution and JSON-escaping bugs, while global-option handling can trigger unwanted configuration-dependent startup or reject supported invocations.

4 open issues

• Detect plugin subcommands regardless of root option placement · New
• Register --no-color on the standalone plugin command · New
• Resolve relative plugin paths before returning them · New
• JSON-escape plugin paths in the usage hint · New

What changed in this PR

Adds devproxy plugin list to discover built-in and custom plugins without reflection scripts, addressing #2056. The command uses the existing plugin-loading infrastructure and runs independently of configuration loading.

Changes:

• Adds text and JSON output with plugin names, paths, and configurability.
• Registers the command in root help and adds standalone startup handling.
• Adds discovery and output tests, and documents the command.

File	Description
skills/​dev-proxy/​references/​plugin-catalog.md	Documents plugin discovery commands.
DevProxy/​Program.cs	Routes plugin commands through standalone handling.
DevProxy/​Plugins/​PluginServiceExtensions.cs	Exposes configurability detection for reuse.
DevProxy/​Commands/​PluginCommand.cs	Implements discovery, output formatting, and standalone parsing.
DevProxy/​Commands/​DevProxyCommand.cs	Registers and detects the plugin command.
DevProxy.Tests/​PluginCommandTests.cs	Tests filtering, configurability, missing assemblies, and output.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Custom-assembly discovery can report success with unloadable partial results and advertise open generic plugins that the runtime cannot instantiate.

No open issues 🎉

2 previously missed issues

In code that hasn't changed since last review

Fail plugin listing when assembly type loading is incomplete

DevProxy/​Commands/​PluginCommand.cs:164

When a custom assembly has a missing type dependency, this silently returns a partial list (or an empty list) with exit code 0. However, the runtime loader calls assembly.GetTypes() without this fallback in PluginServiceExtensions.cs:156, so even the plugins listed here cannot be registered from that assembly. Report the loader exceptions and return a failure instead of presenting the partial result as usable plugins.

Exclude open generic types from plugin discovery

DevProxy/​Commands/​PluginCommand.cs:168

This filter also includes open generic plugin classes, such as a public, non-abstract CustomPlugin<T> : BasePlugin. Their names appear as CustomPlugin followed by a backtick and generic arity, but the runtime's ActivatorUtilities.CreateInstance cannot instantiate a type containing generic parameters. Exclude these types so custom-assembly output only advertises plugins that can be instantiated.

4 resolved since last review

• JSON-escape plugin paths in the usage hint
• Resolve relative plugin paths before returning them
• Register --no-color on the standalone plugin command
• Detect plugin subcommands regardless of root option placement

_{Review effort: Balanced}

[waldekmastykarz]

Addressed the two previously missed issues from the last review:

• Plugin listing now fails (exit 1, loader messages on stderr) on ReflectionTypeLoadException instead of returning partial results, matching the runtime loader.
• Open generic types are excluded from discovery (with a test).

[Copilot]

🟡 Changes recommended

Plugin discovery can silently succeed with incomplete or runtime-unloadable results when dependencies are missing, and it rejects valid backslash-separated plugin paths on Linux/macOS.

2 open issues

• Normalize path separators before resolving plugin paths · New
• Fail discovery when plugin dependencies cannot be loaded · New

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human assessment is needed because regression tests do not exercise standalone command execution or on-disk plugin loading, leaving configuration independence and plugin discovery unverified.

No open issues 🎉

2 resolved since last review

• Fail discovery when plugin dependencies cannot be loaded
• Normalize path separators before resolving plugin paths

_{Review effort: Balanced}