Atlas self-configure

Atlas's user-facing preferences live in one human-editable file, config.toml. This skill is how you (an agent) read and change it safely, without touching anything else Atlas persists.

Where the file lives

~/.config/atlas/config.toml

The same path on every platform. If $XDG_CONFIG_HOME is set to an absolute path, it's $XDG_CONFIG_HOME/atlas/config.toml instead, check that variable before assuming.

Editing that file is the supported mechanism, and the only one available to you: Atlas's config commands are IPC endpoints reachable from its own UI, not agent tools. Atlas watches the file and validates every change you make (see step 6 below), so a direct edit is a first-class way in, not a workaround.

If the file does not exist yet, Atlas hasn't created it (a fresh install before first launch, or the user deleted it). Do not create one speculatively, report that to the user instead of guessing at defaults.

One project only: the project's own config.toml

A project can override a few keys for itself in a config.toml inside the project's .atlas/ directory. Use it only when the user asks for a change in this project rather than everywhere. Its header says what it is; the rules:

• It holds only the keys the project changes. The allowed keys are the ones whose comment in the global file says a project can override it. Atlas ignores any other key there.
• Some of those a project can only turn off (the comment says "never on"). If the user wants one on for a single project while it's off everywhere else, say that Atlas won't honour it and stop.
• Delete a key's line to go back to the global value.
• The same care applies as below: read first, explain, change only your lines, write atomically. It may not exist yet; unlike the global file, creating it is fine, start it with schemaVersion = 1 and [settings].

The schema is in the file