base.toml and is addressed with dot-notation keys. Start with list, because it shows you the keys that exist and what they are currently set to, which beats guessing at a key name.
Why it works. base.toml layers the same way everything else does: the workspace file overlays the global one by key, and inherits everything it does not override. So base config list inside a workspace shows you the merged result rather than one file.
The toggles worth knowing about
The gotcha.
devmode.enabled is for tuning, not for living in. Turn it back off, because it adds output to every hook event and the noise stops being informative quickly.
Next rung. grounding.enabled is the one people do not know about. If you are using base to hold facts you will act on, having every injection carry an instruction to verify claims against a source is worth the tokens it costs.
Secrets
base secret set prompts with echo off. You paste the value, it is masked as you type, and it is never printed back. It lands in ~/.base-gbl/.env with 0600 permissions, and plugins read it from their environment.
The point is the thing that does not happen: the key is never an argument, so it never reaches your shell history, and it is never typed into a chat, so it never reaches a transcript.
The gotcha. base secret list shows key names with masked values and never the full secret, which is what makes it safe to run while someone is watching your screen. base secret rm is a hard delete with no preview.
Next rung. .env is the one file in the global tier that should never be copied to another machine. Everything else there is either policy you wrote or state about this install. See Where things live.
Your identity
~/.base-gbl/operator.toml and is loaded alongside everything else, so an agent knows who it is working for without being told each session.
Next
Extensions
Adding commands to base, and checking one before you trust it.
Setup reference
Every config, secret and operator command.