Reference

Settings

Every setting, its default and what it does, read out of the types the code itself reads. A value that is not a valid choice is refused at startup rather than quietly ignored.

Where each one goes

A setting is a choice about how the runtime behaves, so it goes in chloe.config.ts under settings, where TypeScript checks it and source control keeps it. What the file leaves out is the default, so there is nothing to write down twice. Every password, key and token goes in .env beside it instead, mode 600 and out of source control. The server reads both again when either changes.

A key is named in the config

The runtime reads no setting from the environment by itself. A key reaches it only where the config hands it over, as process.env and its name in .env, so reading the config shows every key there is and where each comes from. The keys are the rows marked above: the model's key, Resend's, the Google client, and every agent's channel tokens under agents.

settings: {
  model: { key: process.env.CHLOE_MODEL_KEY },
  connections: { resend: { api_key: process.env.CHLOE_CONNECTIONS_RESEND_API_KEY } },
  agents: { tempo: { telegram: process.env.CHLOE_AGENTS_TEMPO_TELEGRAM } },
}

npx chloe setup writes those lines, and a message that says a key is missing says both halves: the name in .env, and the line in the config.

Anything else from .env

Any other setting can be kept out of the file the same way, by handing it over as process.env and a name. The runtime still reads only what the config says. Where things are kept is the one exception: CHLOE_STATE, CHLOE_MEMORY and CHLOE_DB are read from the environment before the config is, and are not settings.

core/settings.ts