Skip to main content
The config command manages layered CLI defaults — global, project, environment, and runtime flags merged into one resolved config.

Quick Start

1

Set a default model

2

Verify resolution

Usage

Commands

show

When mcp or permissions are set in any config layer, praisonai config show includes those sections in the output.

validate

Validates discovered config files against the schema, catching typos with difflib-based suggestions.
Example output for a typo:

sources

Prints the five-layer hierarchy and which global/project/env sources are currently active.

provenance

Prints the reconciled resolved view: every key that survived the deep-merge, its winning value, its layer (defaults / global / project / environment / cli), and the absolute path of the file that supplied it ((runtime) for env / CLI / built-in defaults). Reach for this when praisonai config show returns a value you did not expect and you need to find which file set it. Single key, text output:
All keys, text output:
JSON output (via the global --json flag):
A missing key exits 1 with Key not found: <key>.

set / get / reset / path

praisonai config set / praisonai config reset write TOML to the canonical ~/.praisonai/config.toml. Both the canonical home and the config.yaml written by setup / init honour PRAISONAI_HOME — see CLI Home Root.

Strict Validation

Unknown or mistyped keys are reported with the closest valid match. By default they are warnings — your valid keys still apply. Opt into strict mode to fail-fast.
The validator inspects the raw discovered config (before normalisation through ResolvedConfig), so nested mistakes like agent.temprature surface instead of being silently dropped.

Configuration File

Primary format is YAML at ~/.praisonai/config.yaml (global) or ./.praisonai/config.yaml (project):
Model lives under agent.model, not at the top level. See CLI Configuration for the full schema.

Project discovery

From cwd, the resolver walks up to the git root or $HOME (whichever comes first) searching:
  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 global; loaded exclusively as global: when at $HOME)
At $HOME the legacy .praison/config.toml name is skipped — it is loaded exactly once as global: by the global loader (see Walk-up Boundaries).

Value Interpolation

Every value in every discovered config file is interpolated at load time, so secrets and reused prompt bodies can live outside your tracked config. All four in one file:
{file:} reads are confined to the directory of the config file being loaded. Absolute paths, home-relative (~/…) paths, and ../ traversals that escape that directory are all refused — the literal directive stays in the value and no file is read. Interpolation runs in a single pass, so an expanded ${VAR} that itself contains {file:…} is never re-scanned (no chained-directive injection). A {file:} directive with no base directory (e.g. an ad-hoc string) is refused entirely.
${VAR} and {env:VAR} with no default are preserved as-is when the variable is unset — the directive stays visible in praisonai config show so a typo doesn’t silently become an empty string.

From Python


agent.* Schema

Store API keys via env vars or praisonai authapi_key is never written to YAML.
Editor autocomplete: praisonai init writes a # yaml-language-server: $schema=... pointer to config.schema.json. VS Code (YAML extension) and other LSP editors validate against the published schema.

mcp.servers.<name> Schema


permissions.* Schema


Environment Variables


Legacy Formats

Legacy paths still work and are migrated on read: TOML [rules], [output], [mcp], [traces], and [session] sections remain valid in legacy files. New projects should use YAML.
The CLI wrapper now roots sessions, traces, logs, cache, and state under the canonical ~/.praisonai/ home (override with PRAISONAI_HOME). The legacy ~/.praison/config.toml is read-only: writers (config set, reset) always land on the canonical path, so an update never mutates the legacy file — migration is one-way.

See Also