Configuration overview

Jarvis configuration is layered on purpose. The product is easier to operate when you keep these layers separate instead of pushing every setting into a single file.

What belongs where

Layer	Use it for	Typical examples
`.env` and `JARVIS_*` variables	Jarvis server infrastructure and optional built-in provider credentials	`JARVIS_PORT`, `JARVIS_DATABASE_PATH`, `JARVIS_API_KEY`
Model pool UI	Main chat model selection and user-managed provider entries	chat defaults, custom providers, model switching
Runtime CLI configuration	Claude Code, Codex, and OpenCode local auth and defaults	runtime login state, default model, CLI-specific behavior
Worker tools and permissions	What coding sessions can report, request, or inspect while they run	progress reports, blocked state, human questions, optional `search_kb`

Core principle

Use .env for infrastructure, use the model pool UI for the main chat model, and let runtime CLIs keep their own local configuration unless you explicitly override a launch.

Main chat model vs runtime models

Jarvis has one main chat surface and several coding runtimes. They are related, but they are not configured in the same place.

The main chat reads from the model pool.
Claude Code, Codex, and OpenCode usually read from their own local CLI setup.
Jarvis can inject a model override for a runtime launch, but that is an explicit action, not the default behavior.

This separation prevents a runtime-specific change from unexpectedly changing the main chat experience.

Environment variables you will see most often

The public configuration surface starts with three variables:

Variable	Meaning	Default
`JARVIS_PORT`	Port used by the Jarvis HTTP server	`8888`
`JARVIS_DATABASE_PATH`	Path to the SQLite database file	`data/jarvis.db`
`JARVIS_API_KEY`	API authentication key used to access Jarvis	none; generate one for protected access

Jarvis also exposes optional credential slots for built-in providers. Those fields exist so the model pool can route through a known provider without hard-coding secrets in page content or repository files.

Provider credentials

Provider credentials appear in two different places depending on how you use the provider:

Built-in providers: add the relevant JARVIS_*_API_KEY field in .env.
Custom providers: add them through the model pool UI.

That keeps public documentation clean and lets users decide where credentials should live in their own environment.

Runtime CLIs

Jarvis does not ask users to rebuild Claude Code, Codex, or OpenCode configuration inside Jarvis.

Instead:

install the runtime CLI,
authenticate it using the runtime’s official flow,
let Jarvis discover and launch sessions against that local setup.

This is why a runtime may fail even when the main chat works: the chat provider and the runtime CLI can be configured independently.

Permissions and privacy

Permissions are part of configuration because coding sessions can touch local code, local credentials, and user data. Public guidance for Jarvis should always assume:

secrets must be redacted before they appear in issues or screenshots,
public feedback must not include private logs or raw session transcripts,
optional tools such as search_kb must degrade safely when not configured.