lairen 来人
Bring the right CLI-agent identity to the right place.
Full documentation: https://igamenovoer.github.io/lairen/
lairen is a Python credential registry and deployer for CLI coding agents.
It stores a provider login once, then materializes it into any target home on
demand — project-local, holder directories, or throwaway worktrees.
Status: 1.3.0, Pixi-managed, Click-based. Codex and Kimi are the tested
adapters; the other provider adapters are implemented but remain experimental
because this project has no live credentials for them yet. Remote quota
queries and OAuth refresh are the next milestones.
Why
- Keep credentials out of project repos and out of a single global home.
- Deploy a saved login into an arbitrary provider home.
- Preserve session-level Kimi identity:
(user_id, device_id), not justuser_id, so independent logins of one account stay addressable. - Inspect expiry and usage from one command, including machine-readable JSON.
- Use explicit CLI arguments first; common provider environment variables are respected only as fallbacks.
Requirements
- Python
>=3.11(the Pixi environment pins the 3.11 line) - Pixi for the managed development environment
- Click for the CLI
Install
Recommended with uv:
uv tool install lairen
lairen --help
Run it once without installing:
uvx lairen --help
Add it to an existing uv project:
uv add lairen
From a source checkout:
uv venv
uv pip install -e .
uv run lairen --help
For project development, use Pixi:
pixi install
pixi run lairen --help
pixi run test
Quick start
Codex and Kimi are the tested paths:
# Register a Codex home (reads auth.json, never prints tokens)
lairen register codex --home ~/codex-holder/.codex
# Register a Kimi home (reads credentials/kimi-code.json)
lairen register kimi --home ~/kimi-homes/kimi-2064-1 --alias kimi-2064-1
# List saved identities
lairen list
# Deploy a saved login into a project-local home
lairen deploy codex/alice@example.com --home ./my-project/.codex
lairen deploy kimi-2064-1 --home ./my-project/.kimi-code
# Pull tokens refreshed in a project home back into the store
lairen sync kimi-2064-1
# Replace a stored credential from a new home, keeping the alias
lairen update kimi-2064-1 --home ~/kimi-homes/kimi-2064-1
# Show which accounts a project is using, with aliases and other leases
lairen status ~/my-project
# Usage / expiry report (alias: stats)
lairen usage
lairen usage kimi/alice--device-id --json
Scanning
Discover Codex and Kimi credential homes under a directory:
lairen scan ~/code --depth 2
lairen scan ~/kimi-homes --depth 1 --provider kimi
lairen scan ~/tmp/workspace --register
lairen scan ~/code --depth 2 --json
Depth 0 checks only the given directory; depth 1 (the default) also checks
its immediate children, so ~/code/project/.codex is found at the top level.
Symlink directories and common noise directories (.git, .pixi,
node_modules, caches, build outputs) are skipped.
Known patterns:
- Codex:
<dir>/auth.jsonand<dir>/.codex/auth.json, validated by Codex auth fields. - Kimi:
<dir>/credentials/*.json,<dir>/.kimi-code/credentials/*.json, and<dir>/.kimi/credentials/*.json, validated by Kimi token fields. This includeskimi-code.jsonandkimi-code-env-*.jsonnames.
Without --register, scan only reports findings. With --register, it
saves each unique account and keeps the newest copy when the same account
appears in multiple homes. Backup copies are reported as findings too.
Provider surface
lairen exposes every provider surface that subswap supports. Adapters
marked tested=no are implemented against the upstream storage layouts but
have not been exercised with live credentials here.
| Provider | Tested | Env fallback | Default home | Credential | Notes |
|---|---|---|---|---|---|
claude |
no | CLAUDE_CONFIG_DIR |
~/.claude |
.credentials.json |
Merges oauthAccount metadata on deploy |
codex |
yes | CODEX_HOME |
~/.codex |
auth.json |
ChatGPT OAuth |
commandcode |
no | COMMANDCODE_HOME |
~/.commandcode |
auth.json |
API-key auth |
cursor |
no | CURSOR_HOME |
~/.config/Cursor/User/globalStorage |
state.vscdb |
Desktop SQLite; close Cursor before deploying |
kimi |
yes | KIMI_CODE_HOME |
~/.kimi-code |
credentials/*.json |
Session identity user_id--device_id |
opencode |
no | OPENCODE_HOME |
~/.local/share/opencode |
auth.json |
Go API-key slot; Console accounts use the official CLI |
Provider home resolution order:
--home <path>- the provider environment variable (
CODEX_HOME,KIMI_CODE_HOME, ...) - the provider default
Deployment always requires an explicit --home; lairen does not infer a
target from an environment variable.
Commands
| Command | Purpose |
|---|---|
lairen register <provider> [--home PATH] [--label NAME] [--alias NAME] |
Save the live login from a provider home |
lairen update <ref> --home PATH [--label NAME] |
Replace a stored credential from a new home, keeping the alias |
lairen list [--json] |
List saved accounts |
lairen show <ref> |
Show one account and its local usage metadata |
lairen deploy <ref> --home PATH [--refresh] |
Write a saved credential into a target home |
lairen sync [ref ...] [--home PATH ...] [--dry-run] [--strict] |
Pull refreshed credentials from known homes into the store |
lairen scan DIR [--depth N] [--provider P] [--register] [--json] |
Discover Codex/Kimi homes |
lairen status [DIR] [--provider P] [--json] [--strict] |
Show which accounts a project is using |
lairen usage [ref ...] [--json] |
Expiry/usage statistics (alias: stats) |
lairen remove <ref> --yes |
Remove an account from the registry and store |
lairen alias [ref] [name] [--clear] [--json] |
Set, clear, or list stable account aliases |
lairen providers |
Show provider defaults, tested status, and notes |
lairen doctor |
Show resolved paths, account counts, and provider homes |
lairen manual [topic] [--json] |
Agent-oriented manual; manual all loads the full guide |
<ref> is provider/id (for example codex/alice@example.com or
kimi/alice--<device-id>). A unique alias, bare id, or label is also accepted;
aliases resolve before ids and labels. Aliases are unique, survive
re-registration, and can be managed with lairen alias.
Agents can load the complete usage guide in one call:
lairen manual all
lairen manual all --json
Storage
~/.config/lairen/
registry.json # account metadata: provider, id, label, alias, source
~/.local/share/lairen/
credentials.json # credential blobs, mode 0600
state/snapshots/ # pre-deploy copies of overwritten target files
state/deployments.jsonl # append-only deploy/update/remove history
Set LAIREN_HOME=/absolute/path to keep config, data, and state under one
root. This is a development and testing override, not an input mechanism for
provider selection.
Design
- Registry and credentials stay separate. Metadata is readable; secrets
live in one
0600JSON file. - Deployment is atomic. Target files are written through a temporary file
and
os.replace, with a pre-deploy snapshot when the target already exists. Provider-specific adapters merge rather than replace where upstream expects it (OpenCode Go slot, CursorItemTable, ClaudeoauthAccount). - Project status reads live homes.
lairen statusmatches a project's actual credentials against the registry and reports unregistered or drifted copies. An append-only deployment log records which projects hold an account. - Kimi identity is a session.
user_idplusdevice_id, joined asuser_id--device_id, so multiple logins of one account remain distinct. - Usage is local-first.
lairen usagereports token expiry and refresh timestamps from stored blobs. Remote quota endpoints plug in behindProvider.local_usage()later.
Development
pixi run test # core + aux unit/integration suites
pixi run test-core # tests for src/lairen
pixi run test-aux # tests for repository support files
pixi run lint
pixi run typecheck
pixi run docs-serve # live documentation preview
pixi run docs-build # strict documentation build
Codex and Kimi are the only adapters with live-credential tests. Other adapters use fake payloads or remain untested until credentials are available.
Project layout
src/lairen/: importable package and Click CLItests/core/: tests for distributed code (unit,integration,manual)tests/aux/: tests for repository support contentextern/: tracked, orphan, and linked-worktree external materialcontext/: plans, features, design, summaries, and archived contextdocs/: MkDocs Material documentation source, published to GitHub Pagesscripts/: repository automation outside the installed packageskillset/: project-specific agent skills
Security
Credential files are stored in plaintext with 0600 permissions, matching the
native clients. Do not commit credentials.json, registry.json, or any
provider home. Rotating OAuth refresh tokens cannot be safely shared by two
active homes at once; prefer one active home per saved session.
Limitations
- Remote quota queries and OAuth refresh/write-back are not implemented.
cursorrequires Cursor to be closed while the SQLite database is updated.opencodecovers the Go API-key slot; Console account switching stays with the official CLI.claude,commandcode,cursor, andopencodeare experimental until live-credential tests are added.scanskips symlinked directories and reports any directory with a matching credential file, including backup copies;--registerkeeps the newest copy.
License
MIT
Metadata
Release files for lairen 1.3.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| lairen-1.3.0.tar.gz | 37.7 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| lairen-1.3.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 80.4 kB
Release files / lairen-1.3.0.tar.gz
| Download URL | lairen-1.3.0.tar.gz |
|---|---|
| Size | 37.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
dfcdbcfc49046a3448d4d20d5ee055df9a57072a687a52fb68b19641ea0af702
|
|
BLAKE2b-256 checksum How to use checksums |
ccb75c8b5cfb34c31bf2eb8d181d37f03da9408a8bfca84e12214499a37ad4cb
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 27, 2026.
Transparency logRelease files / lairen-1.3.0-py3-none-any.whl
| Download URL | lairen-1.3.0-py3-none-any.whl |
|---|---|
| Size | 42.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4e67566e0db1013ec420a8c39fb912e424986a5ee3d87ccda6d1feedf6684b8f
|
|
BLAKE2b-256 checksum How to use checksums |
3a0f0767ac440ab98d856f93d86f95f4e64dcb53e1fe96aba535a7e2453b1587
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 27, 2026.
Transparency logSecurity for lairen 1.3.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for lairen-1.3.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 27, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.