Auth / Runtime Auth

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' }
}

Recommended checks

Use these commands to validate auth behavior early:

npx @orchid-labs/pluxx doctor
npx @orchid-labs/pluxx lint
npx @orchid-labs/pluxx build

Start

Build

Learn

Platform Guides

Examples

Reference

Auth / Runtime Auth

Import-time auth

Runtime auth

Recommended checks

​Import-time auth

​Runtime auth

​Recommended checks

Import-time auth

Runtime auth

Recommended checks