Skip to main content
The praisonai CLI reads defaults from a layered hierarchy so you can set a model once and have it work everywhere — globally, per project, or per command.
The user sets a default model in config once; every praisonai command in that project picks it up without repeating flags.
See also: Env Config Injection — supply the whole config layer from PRAISONAI_CONFIG_CONTENT / PRAISONAI_CONFIG with nothing on disk.

Quick Start

1

Set a default model

2

Run any agent

The model from config is picked automatically — no --model flag needed.
3

Inspect what was resolved

When you praisonai run, CLI defaults flow into the agent automatically:

How It Works

Layers are deep-merged. Lists are concatenated. Scalars are overridden by higher layers.

Project vs Global Config

† When placed directly at $HOME, .praison/config.toml is loaded once as global: (never as project:).
Canonical name (PR #3422): praisonai.yaml is the canonical project-root config name — it matches praisonaiagents/config/loader.py, praisonai-code/.../diag.py, and the TS CLI. The praison.yaml / praison.yml legacy names are still discovered by the resolver for backward compatibility. When both praisonai.yaml and praison.yaml exist in the same directory, the canonical name wins (asserted by the regression tests).
Walk-up discovery searches, at each directory from cwd up to the git root or $HOME (whichever comes first). At $HOME the legacy .praison/config.toml name is skipped — that file is owned by the global loader:
  1. .praisonai/config.yaml
  2. .praisonai/config.yml
  3. praisonai.yaml / praisonai.yml (canonical project-root config, added in PR #3422)
  4. praison.yaml / praison.yml (legacy fallback, discovered for backward compat)
  5. .praison/config.toml (legacy)

Walk-up Boundaries

Walk-up stops at the nearer of two boundaries: a .git-marked directory or $HOME.
  • The walk stops at the nearer of a .git-marked directory or $HOME.
  • $HOME itself is still searched for project configs, so ~/.praisonai/config.yaml and ~/praisonai.yaml remain discoverable.
  • The legacy .praison/config.toml name is skipped only at $HOME — that file belongs to the global loader and is loaded exactly once as global:.
  • A config placed above $HOME (e.g. /Users/praisonai.yaml in a shared-parent layout) no longer wins, because $HOME is now a hard boundary.
  • If $HOME is unresolvable (Path.home() raises), the walk falls back to filesystem root.
  • The CLI home root (sessions, traces, logs, cache, model-recency) is now the canonical ~/.praisonai/ — the same directory praisonai setup and the SDK use — unless PRAISONAI_HOME overrides it. A legacy ~/.praison/ is read-only when it is the sole directory present.
praisonai config sources shows ~/.praison/config.toml exactly once, with the global: label — never duplicated as project:, even when the CLI runs from $HOME or a subdirectory beneath it.

Choose Your Scope


CLI Home Root

The CLI writes everything under one directory — ~/.praisonai/ by default, or wherever PRAISONAI_HOME points. Config, sessions, traces, logs, cache, credentials, .env, and durable state all live together there. Every user-scoped artefact resolves under the same home root:

Override with PRAISONAI_HOME

Set PRAISONAI_HOME to re-root every artefact together — config and sessions and traces and logs and cache all move as one.
Tilde is expanded, so PRAISONAI_HOME=~/mycustom resolves the same as PRAISONAI_HOME=$HOME/mycustom.

Legacy ~/.praison/ — read-only fallback

If an older install still has ~/.praison/config.toml, the CLI keeps reading it until the first write. Any praisonai config set / praisonai config reset seeds from whatever currently resolves, then writes the merged result to ~/.praisonai/config.toml — migrating legacy values forward without ever mutating the legacy file. The SDK honours the legacy directory the same way (with a deprecation warning); praisonai migrate-data moves everything to the canonical root.

Configuration Schema

agent.* defaults

api_key is never serialised to YAML — use environment variables or praisonai auth.

mcp.servers.<name>

permissions.*

instructions

Top-level list of extra instruction/context sources loaded alongside the convention-only AGENTS.md / CLAUDE.md auto-discovery. List values concatenate across the config hierarchy (global → user → project), so a project extends rather than replaces the org-wide list.
Same first-class, layerable status as agent.*, mcp.servers.*, and permissions.* — also mirrored by the repeatable praisonai run --instructions <path|glob|url> flag. Example combining all three sections:
See Single-Source Config for a full guide to using all three sections together. Other top-level sections (output, traces, session) are also valid — see Config CLI reference.

Validation

Configuration is validated against a published JSON Schema. Unknown keys produce actionable warnings with typo suggestions; opt into strict mode to fail fast. Typo example:
The # yaml-language-server: $schema=... line written by praisonai init enables real-time autocomplete and inline errors in VS Code (YAML extension) and other LSP-aware editors against the published schema.
Editor autocomplete works for both the CLI config file (.praisonai/config.yaml, validated against config.schema.json) and the agent definition file (agents.yaml, validated against agents.schema.json). Full setup: Editor Support.

Environment Variables


Subcommand Reference


Backward Compatibility

Loaded once as a global: source by the global loader. RAG and model keys are migrated to the new agent.* / rag.* schema automatically. Project walk-up never re-discovers it at $HOME, so praisonai config sources shows it exactly once with the global: label.The legacy file is read-only. praisonai config set / praisonai config reset always write to the canonical ~/.praisonai/config.toml, seeding from whatever currently resolves — so a first write migrates any legacy values forward and the legacy file is never mutated after that. The same applies to the whole legacy directory: sessions, traces, logs, and cache now live under the canonical home too.
Model and provider keys from .env are merged into the resolved config when no YAML is present.
Walk-up discovery still finds legacy TOML project configs in subdirectories (e.g. <subdir>/.praison/config.toml) and migrates them on read. The exception is the file at $HOME itself, which is only ever loaded as global: (see above).

Best Practices

Commit .praisonai/config.yaml to your repo so teammates get the same defaults.
api_key is never serialised; use env vars or praisonai auth.
When behaviour surprises you, praisonai config sources prints exactly which layer won.
Running praisonai from repo/scripts/ finds repo/.praisonai/config.yaml.

Interpolation & Provenance

Any config value can reference ${VAR}, {env:NAME:-default}, or {file:./relative/path} — see Value Interpolation for the directive table and its security rules. Run praisonai config provenance to see the winning value of each key and the exact layer/file that supplied it — see provenance.

Config CLI Reference

Full subcommand reference for praisonai config

Configuration Index

SDK-level agents, tasks, and memory configuration

Runtime Selection

Model-scoped runtime configuration

LLM Endpoint Config

Custom base URLs and provider routing

Single-Source Config

Model + MCP + permissions in one file

Editor Support

Autocomplete and inline validation for config.yaml and agents.yaml