How sign-in works

Eddytor uses passwordless magic-link and device-code sign-in - no passwords to manage.

Eddytor has no passwords. People sign in with a magic link (in the browser) or a device-code flow (from the CLI and MCP clients). The server issues short-lived session tokens; long-lived programmatic access uses API keys.

Magic-link (browser / Web UI)

Enter your email, receive a one-time link, click it, you're in.

Heads up

With no SMTP configured (the default), the link is written to the server logs instead of emailed. Fine for a solo operator; configure SMTP so teammates can receive links.

Read the link from the logs when SMTP is unset:

docker compose logs eddytor-server | grep -i 'sign in to eddytor' -A2

Device-code (CLI / MCP)

The CLI logs in like kubectl - a device-code flow that opens your browser to approve:

eddytor config set-api-url http://localhost:8080
eddytor login        # opens the browser; approve, and the CLI caches the token

MCP clients (Claude Desktop, Cursor) trigger the same OAuth 2.1 device-code flow on first use - approve in the browser and the client caches the token. See MCP clients.

Token lifetimes (the gotcha)

Credential	Lifetime
Device-login token (`eddytor login`)	15 minutes, not auto-refreshed by `eddytor query`
Bootstrap API key (`eddytoradm create-api-key`)	Does not expire

Heads up

Use an API key, not eddytor login, for eddytor query. The login token expires in 15 minutes and query won't refresh it, surfacing as GetFlightInfo failed: Invalid or expired token. See the fix.

First admin & recovery

The first admin is created inside the container with eddytoradm - see Bootstrap the first admin. Lost access? Nothing to recover; re-run the in-container tools (the boundary is exec access, not a secret) - Can't sign in.

API keys · Roles & scopes · SSO with OIDC.

Magic-link (browser / Web UI)

Device-code (CLI / MCP)

Token lifetimes (the gotcha)

First admin & recovery

Next

On this page