atlas-self-configure

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.

The schema is in the file

Atlas writes a comment above every key: what it does, its default, and any constraint on its value — a numeric range, an exact set of allowed strings, "must not be empty". Read those comments and follow them. They are generated from the same table Atlas validates against, so they cannot drift from what it will actually accept.

Do not work from a schema you remember, or from one you saw in another project. The file in front of you is authoritative, and it is the only thing guaranteed to match the Atlas build the user is running.

Two things the comments won't spell out:

• A key that isn't there. Some settings mean "unset" by being absent — TOML has no null. The comment for such a key sits above whichever key follows it, so read the whole [settings] block, not just the lines with values on them. To clear one of these, delete its line; never write an empty string.
• A key Atlas doesn't recognize. It's preserved untouched and reported to the user as a diagnostic. Never delete a key you don't recognize.

Making a change