@hank-warren/pi-multi-login

Register additional OAuth logins for Pi's built-in providers under aliased provider ids, managed with /multi-login.

Packages

Package details

extension

Install @hank-warren/pi-multi-login from npm and Pi will load the resources declared by the package manifest.

$ pi install npm:@hank-warren/pi-multi-login
Package
@hank-warren/pi-multi-login
Version
0.3.2
Published
Aug 31, 2026
Downloads
653/mo · 18/wk
Author
hank-warren
License
MIT
Types
extension
Size
29.4 KB
Dependencies
0 dependencies · 2 peers
Pi manifest JSON
{
  "extensions": [
    "./index.ts"
  ]
}

Security note

Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.

README

@hank-warren/pi-multi-login

Register a second (third, fourth…) OAuth login for any provider Pi already knows how to sign in to. Each additional login is an ordinary provider with its own id — openai-codex-work, anthropic-personal — so it gets its own credential slot in auth.json while reusing the base provider's OAuth flow, transport and model catalog.

Use it to keep a subscription account separate from a work account, or to give a background reviewer (such as @hank-warren/pi-auto-permissions) a dedicated login that never competes with your interactive session for rate limits.

Install

pi install npm:@hank-warren/pi-multi-login

Try it without installing:

pi -e npm:@hank-warren/pi-multi-login

Usage

Run /multi-login in an interactive session:

  • Add a login… — pick a base provider, type a suffix. The alias is written to the config file and registered immediately; then run /login, pick the alias, and complete OAuth there.
  • An existing alias — remove it, which deletes both the credential and the provider.

All authentication goes through Pi's own /login — signing in for the first time and re-authenticating later (token expired, wrong account) both work there, because aliases are ordinary providers. /multi-login deliberately never drives an OAuth flow itself: /login implements every prompt type a provider's flow can emit (including the option choice OpenAI Codex asks for), so there is exactly one login path to keep correct. Aliases also appear in /model and pi --list-models with no extra work.

Once an alias has a credential you can select it like any other model:

pi --model openai-codex-work/gpt-5.6-sol -p "say hi"

Configuration

Aliases live in:

~/.pi/agent/pi-multi-login.json

When PI_CODING_AGENT_DIR points elsewhere, the configuration follows that agent directory. Set PI_MULTI_LOGIN_CONFIG to use an explicit file path.

{
  "aliases": [
    { "base": "openai-codex", "suffix": "auto-permissions" },
    { "base": "anthropic", "suffix": "work", "name": "Anthropic (work)" }
  ]
}
Field Required Meaning
base yes Provider id whose OAuth flow, transport and model catalog the alias reuses. It must expose an OAuth login, and it must not itself be an alias.
suffix yes Lowercase slug (^[a-z0-9]+(-[a-z0-9]+)*$) appended to base. The provider id is always `${base}-${suffix}`.
name no Display name. Defaults to `${baseProviderName} (${suffix})`.

/multi-login rewrites this file, but editing it by hand is supported — the format is the point. Unknown fields are ignored; a malformed file registers no aliases and reports the problem once at session start.

The providers that can act as a base are the ones Pi offers an OAuth login for: anthropic, github-copilot, kimi-coding, openai-codex, openrouter, radius, xai. /multi-login lists whatever the running Pi version actually offers.

How it works

Aliases register during the extension load phase rather than at session_start. pi --list-models, pi --model provider/id and pi auth all run before any session exists, so a session-only registration is invisible to them. Load-phase registrations are queued and flushed before every extension's session_start, so other extensions see the aliases regardless of load order.

At session_start each alias is re-cloned from the composed base provider, so an alias inherits any transport reshaping a config overlay applies to its base (this is what keeps an anthropic alias working under @gotgenes/pi-anthropic-auth).

Model lists are snapshots taken at clone time; the base provider remains the sole owner of catalog refresh.

Adoption of existing credentials

The first time the extension runs without a config file, it scans auth.json for credentials whose id is not itself a provider id but does extend one — openai-codex-auto-permissions extends openai-codex — and adopts them as aliases. The base is the longest matching OAuth provider id, which is what keeps openai-codex-auto-permissions attached to openai-codex rather than to openai.

This makes the package a drop-in replacement for the dedicated login that @hank-warren/pi-auto-permissions used to register itself. The scan runs once: writing the config file (even as {"aliases": []}) is what prevents it from running again, so an alias you delete stays deleted.

Cost

A host with no aliases and an existing config file does no work at startup beyond reading one small JSON file — no model runtime, no network.

License

MIT