App Data and Paths
Desktop app paths
Section titled “Desktop app paths”The desktop app stores runtime data in app-specific operating-system directories. That keeps local state separate from your source repositories.
On macOS, packaged production releases use the com.maabarium.console runtime namespace under ~/Library/Application Support and ~/Library/Logs.
The packaged release paths are:
~/Library/Application Support/com.maabarium.console/maabarium.db~/Library/Logs/com.maabarium.console/maabarium.log~/Library/Application Support/com.maabarium.console/blueprints/~/Library/Application Support/com.maabarium.console/bin/maabarium
Debug builds use a separate development namespace so local release testing does not automatically mix with day-to-day development data.
On supported packaged desktop builds, the bundled CLI is seeded into the desktop app-data bin/ directory from the app’s packaged generated-resources/cli/... payload. When the shipped bundled binary changes, Maabarium refreshes the seeded copy on startup. If you enable shell integration, Maabarium also manages a separate symlink at ~/.local/bin/maabarium that points at that seeded binary.
Repository-local paths
Section titled “Repository-local paths”The CLI defaults to repository-local runtime files such as:
data/maabarium.db- shared trace and log output
Why this matters
Section titled “Why this matters”Knowing where data lives helps you answer practical questions:
- What should I back up?
- What can I safely delete?
- Which files should be attached to a bug report?
- Why does the desktop app behave differently from a repo-local CLI run?
Good operating practice
Section titled “Good operating practice”- treat logs and persisted experiment data as part of your debugging surface
- do not assume deleting runtime files is harmless during an active investigation
- if you migrate machines, migrate the runtime data you actually care about, not just the app binary
- if you want a truly fresh packaged-release test on macOS, back up or reset the existing
com.maabarium.consoleapp data first instead of assuming the app bundle contains all state - if you enabled the shell CLI link, remove it through the app before deleting the desktop bundle if you want the terminal integration cleaned up too