> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pluxx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

```bash theme={null}
npx @orchid-labs/pluxx init --from-mcp https://example.com/mcp --auth-env API_KEY --auth-type bearer
```

```bash theme={null}
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:

```ts theme={null}
platforms: {
  'claude-code': { mcpAuth: 'platform' },
  cursor: { mcpAuth: 'platform' }
}
```

## Recommended checks

Use these commands to validate auth behavior early:

```bash theme={null}
npx @orchid-labs/pluxx doctor
npx @orchid-labs/pluxx lint
npx @orchid-labs/pluxx build
```