Skip to main content
Settings live in plain text files. The same files decide how basset behaves in your terminal and how a basset mcp server answers an agent, so a change reaches both.
Prints every setting, its value, and the file it came from. A setting nothing has named reads as unset.

​
Settings

​
Where settings come from

Each setting is read from the first place that names it:
  1. A flag on the command, such as --org.
  2. The matching environment variable — BASSET_ORG, BASSET_APP, BASSET_ENDPOINT, BASSET_PLAINTEXT, BASSET_DSYM_PATH, BASSET_SYMBOLICATE.
  3. The nearest .bassetrc, searching up from the current directory.
  4. ~/.config/basset/config.
  5. For org only, the organization stored when you signed in.
basset config names the file every value came from, so a setting is never applied from somewhere you cannot see. Both files are read fresh each time a setting is used. Editing one reaches a running basset mcp server on its next call — you do not need to restart it.

​
Your settings

Written by basset org select and basset app select, and safe to edit by hand. It does not exist until one of those runs or you create it.
One setting a line, key = value, and # starts a comment. If XDG_CONFIG_HOME is set, the file lives under that instead. This is also where basset auth login writes the credential, in credentials.json beside it. Keep that file out of version control — it carries the token that signs your requests.

​
A repository’s settings

Put this at the root of a repository for the settings that belong to the code rather than to you. basset searches upward from wherever it runs, so it applies in every directory beneath.
org and endpoint describe your account and your machine, so they belong in your own file. app and dsym-path describe the repository, so they belong here, and a .bassetrc is worth committing. A relative dsym-path resolves against the file that names it, which is what keeps a committed one correct on a teammate’s machine. An absolute path is left alone.

​
Resolving captured addresses

Some instruments report where in your own code something happened, as addresses rather than names. Resolving them needs the dSYM for the exact build that ran, matched by its build UUID. basset looks for one in dsym-path, then in a Bazel output tree if it finds one above the working directory, then in Spotlight’s index, then in Xcode’s archives and derived data. Nothing is uploaded and no address leaves your machine. When no matching dSYM is found, the readings still arrive with their addresses intact and say which build they needed. Set dsym-path to point at wherever your build writes them:
Set symbolicate = false to turn resolution off entirely.