Getting help

TL;DR — Bug reports and feature requests go to GitHub Issues on the relevant repo. Questions and discussions go to GitHub Discussions. Security vulnerabilities go to Private Vulnerability Reporting. Most issues get a response within one business day. Include the version + redacted config + logs with trace_id and you’ll get help fast.

Where to go

TypeWhere
Bug in AuthPlane servergithub.com/authplane/authserver/issues
Bug in Python SDKgithub.com/AuthPlane/python-sdk/issues
Bug in TypeScript SDKgithub.com/AuthPlane/ts-sdk/issues
Bug in Go SDKgithub.com/AuthPlane/go-sdk/issues
Bug in these docsgithub.com/AuthPlane/docs/issues
Question / discussiongithub.com/authplane/authserver/discussions
MCP client compatibility reportMCP compatibility issue template
Security vulnerabilityPrivate vulnerability reporting — see Security: Reporting vulnerabilities

Most issues get an initial response within one business day. Security reports are acknowledged within 48 hours (SLA).

What to include in a bug report

The faster you can give us these five things, the faster we can help:

1. Version.

$ authserver version
authserver v0.1.x commit=abcdef1 built=2026-01-01T00:00:00Z

For containers: the image tag (docker inspect | grep -i tag).

For SDKs: the version from your dependency file (pip show authplane-mcp, npm ls @authplane/mcp, go list -m github.com/authplane/go-sdk/mcp).

2. Config (redacted).

Full YAML config OR relevant AUTHPLANE_* env vars. Redact:

  • session.secret, admin.api_key
  • All OAuth client_secret, client_secret_ref values
  • data_encryption.aes_master.key_env env-var VALUES (not names)
  • vault_transit.token / approle.secret_id
  • Postgres DSN passwords

AUTHPLANE_* names alone are fine; secret VALUES need redaction.

3. Repro steps.

The minimal sequence that reproduces the failure. If it’s the OAuth flow, a redacted curl for each step is ideal. If it’s an SDK bug, a minimal server.py / server.ts / main.go that triggers it.

4. Log lines (with trace_id).

Grab a few lines around the failure — WARN and ERROR levels are usually enough. Include trace_id so we can follow the request across services. Redact tokens — never post an unredacted access token, refresh token, or session cookie in a public issue.

5. What you expected vs what happened.

One sentence each. Skip “it should work” — say “I expected the token endpoint to return an access token with aud=X; instead it returned 403 access_denied”.

Anti-patterns to avoid

  • “Nothing works.” — nine of ten times, one specific thing doesn’t work. Isolate it.
  • Screenshots of terminals. — paste the text. Screenshots aren’t grep-able and take longer to read.
  • Posting tokens. — never. Redact eyJ... blobs before hitting Send. If we need the token structure, decode the JWT payload and paste the JSON (still redacted for user identifiers).
  • “Same as issue #X but different.” — link the issue you’re comparing to and describe the delta.
  • “Doesn’t work with Claude Code.” — check authserver/docs/compatibility.md first; known Claude Code quirks are documented (see Guides: Connect an MCP client → Known Claude Code quirks).

For feature requests

Open an issue with the tag feature. Include:

  • The problem you’re trying to solve (not the solution you have in mind).
  • Why existing features don’t cover it.
  • Concrete use case with real numbers where possible (“we have 200 agents, each needing X”).

We prioritize based on breadth of demand + alignment with the roadmap. Not everything gets built — but every request gets read.

For MCP client compatibility

If you’re testing a new MCP client and hit spec-drift issues, file via the MCP compatibility issue template. Document which scenarios (C.1–C.10 per compatibility.md) pass/fail. If you can add an automated test to e2e/scenarios/, even better — PRs welcome.

For security

Never open a public issue for a security vulnerability. Use GitHub Private Vulnerability Reporting — details in Security: Reporting vulnerabilities. Coordinated disclosure preserves users and gets you credit.

Commercial / enterprise support

AuthPlane is AGPL-3.0 open source. There is no paid support tier today — GitHub Issues + Discussions are the entire support surface. If you’re deploying at enterprise scale and need contractual support, contact hello@authplane.ai and we’ll point you at the current options.