Skip to main content
Pluxx separates import-time auth from runtime auth. That distinction matters because an MCP can require one auth shape for discovery and a different packaging/runtime strategy once the plugin is installed in a host.

​
Import-time auth

  • bearer token
  • custom header
  • OAuth-derived token env vars
Use import-time auth to let pluxx init --from-mcp ... introspect the server and scaffold the project. Examples: 
npx @orchid-labs/pluxx init --from-mcp https://example.com/mcp --auth-env API_KEY --auth-type bearer

npx @orchid-labs/pluxx init \
  --from-mcp https://mcp.playkit.sh/mcp \
  --auth-env PLAYKIT_API_KEY \
  --auth-type header \
  --auth-header X-API-Key \
  --auth-template '${value}'

​
Runtime auth

Runtime auth is how the generated plugin talks to the MCP after installation. Pluxx compiles runtime auth per host:
  • Claude/Cursor: plugin-managed headers or platform-managed runtime auth (including OAuth-first flows)
  • Codex: bearer_token_env_var, env_http_headers, or http_headers
  • OpenCode: runtime validation in wrapper layer
When to use platform-managed runtime auth:
  • the host should own the login flow
  • the MCP is OAuth-first
  • you do not want Pluxx to materialize headers directly into installed config
Example: 
platforms: {
  'claude-code': { mcpAuth: 'platform' },
  cursor: { mcpAuth: 'platform' }
}
Use these commands to validate auth behavior early: 
npx @orchid-labs/pluxx doctor
npx @orchid-labs/pluxx lint
npx @orchid-labs/pluxx build