Guides
Configuration
jarvis.toml, atomic config writes, and how Jarvis safely rewrites its own settings at runtime.
Jarvis is configured through a single jarvis.toml file. Secrets are the one thing that never live there — those go in your OS credential manager (see first run).
Common sections
| Section | Controls |
|---|---|
[brain] | Primary provider and the fallback order |
[brain.providers.*] | Per-provider model and options |
[brain.routing] | The dispatch heuristics (what counts as “real work”) |
[harness.*] | Which execution backends are enabled |
Atomic writes only
Configuration is never edited in place with a naive file write. Every mutation goes through a single writer that:
- validates the new config against the schema before touching disk,
- takes a backup,
- writes to a temp file and atomically replaces the original,
- runs a synchronous reload test,
- rolls back automatically if the reload fails.
This is comment-preserving and encoding-safe, so your hand-written notes and formatting survive an edit.
Self-modification
Jarvis can change its own configuration at runtime — for example, “[wake word], make your voice a little slower.” That self-modification runs through the exact same validated, lock-protected, rollback-on-failure pipeline as any other write. An allowlist controls which settings are reachable this way; anything not on it cannot be changed by voice.
Skills stay drafts
When Jarvis generates a new skill for itself, it is created in a draft state and is not auto-activated. A generated skill never runs until it has been reviewed — closing off a path where the system could quietly grant itself new capabilities.