krites config¶

What `krites config` does¶

Read, write, validate and locate configuration values without editing YAML by hand. It is the scripting counterpart to the studio's Settings panel; for a guided walk through a subsystem, use krites init instead.

config is a command group and always takes a subcommand.

Subcommands¶

Subcommand	What it does
`config get <key>`	Print one resolved value
`config set <key> <value>`	Write one value to the writable config file
`config unset <key>`	Remove one value from the writable config file
`config list`	Print every resolved key and value
`config path`	Print which config files contributed, and which one writes take
`config validate`	Check the configuration; non-zero exit on any error
`config edit`	Open the config file in `$EDITOR`
`config trust`	Trust a project-local config file's security-sensitive keys
`config migrate-credentials`	Move literal secrets out of the config file

Keys are dot-notation — cull.profile.soft_sharpness, face.enabled, remove.timeout. The full set is in the configuration reference.

How a value is resolved¶

config get and config list show the value after the whole precedence chain has been applied, lowest to highest:

krites' embedded defaults
/etc/krites/config.yaml
~/.krites/config.yaml
a trusted project-local .krites.yaml, if one is discovered
KRITES_* environment variables
flags you actually changed on the command line

A flag left at its default never contributes, so krites config get log.level does not read info back just because --output has a default.

Which file `config set` writes to¶

The highest-precedence writable file layer — normally ~/.krites/config.yaml. krites config path --writable prints exactly which file that is. set, unset and edit all mutate that one file and nothing else.

This is why config unset cannot remove a value supplied by an environment variable or a flag: those layers are not file-backed. Unsetting a key the embedded defaults also supply falls back to the shipped default rather than leaving the key absent.

`config set` type coercion¶

Values are coerced on the way in: true and false become booleans, integers become integers, and everything else is stored as a string. A threshold like cull.profile.soft_sharpness is read as a float regardless, so 180 and 180.0 behave identically.

Sensitive values are masked¶

config get and config list mask sensitive values by default. config get --unmask reveals one; config list has no unmask flag. krites doctor report is redacted with no option to disable it.

What `config validate` catches¶

Missing required keys, type mismatches and unknown keys. It exits non-zero when any of those are found, which makes it usable as a CI gate. It does not check that a configured provider actually works — for that, run krites doctor.

Why a project-local config file is ignored until trusted¶

A .krites.yaml in a repository you cloned is honoured for workflow-tuning keys (logging, output, feature toggles) but its security-sensitive keys — self-update verification, telemetry consent, credentials — are ignored until you run krites config trust. A repository you clone must not be able to silently weaken your update verification.

Trust is bound to the file's exact content. Editing a trusted file revokes trust until you run config trust again. --list shows what is trusted; --forget revokes it.

Moving a literal secret out of the config file¶

krites config migrate-credentials rewrites literal credentials as either an environment-variable reference (--target env, the default) or an OS-keychain reference (--target keychain). Re-running it is safe: anything already migrated is skipped with a reason.

This covers the shared framework's credential keys. The AI-review provider key krites uses is entered in the studio and goes straight to the keychain, so it is never in the config file to migrate.