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.
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
--model flag needed.3
Inspect what was resolved
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).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:
.praisonai/config.yaml.praisonai/config.ymlpraisonai.yaml/praisonai.yml(canonical project-root config, added in PR #3422)praison.yaml/praison.yml(legacy fallback, discovered for backward compat).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. $HOMEitself is still searched for project configs, so~/.praisonai/config.yamland~/praisonai.yamlremain discoverable.- The legacy
.praison/config.tomlname is skipped only at$HOME— that file belongs to the global loader and is loaded exactly once asglobal:. - A config placed above
$HOME(e.g./Users/praisonai.yamlin a shared-parent layout) no longer wins, because$HOMEis now a hard boundary. - If
$HOMEis 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 directorypraisonai setupand the SDK use — unlessPRAISONAI_HOMEoverrides 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.
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.
agent.*, mcp.servers.*, and permissions.* — also mirrored by the repeatable praisonai run --instructions <path|glob|url> flag.
Example combining all three 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:
# 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
Legacy ~/.praison/config.toml
Legacy ~/.praison/config.toml
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.Legacy ~/.praisonai/.env
Legacy ~/.praisonai/.env
Model and provider keys from
.env are merged into the resolved config when no YAML is present.Project .praison/config.toml
Project .praison/config.toml
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
Pin model per project
Pin model per project
Commit
.praisonai/config.yaml to your repo so teammates get the same defaults.Keep secrets out of YAML
Keep secrets out of YAML
api_key is never serialised; use env vars or praisonai auth.Use config sources to debug
Use config sources to debug
When behaviour surprises you,
praisonai config sources prints exactly which layer won.Walk-up means subdirectories inherit
Walk-up means subdirectories inherit
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.
Related
Config CLI Reference
Full subcommand reference for
praisonai configConfiguration 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

