Settings
Settings is where you change controls. It is not the main health dashboard. Live state, degraded services, permission recovery, and system attention belong in Status.
Open Settings from the sidebar footer or the standard app shortcut.
Settings Versus Status
Section titled “Settings Versus Status”| Surface | Use It For |
|---|---|
| Settings | Provider keys, plugin credentials, account, consent controls, lifecycle choices, and preferences. |
| Status | Helper health, runtime readiness, encryption state, local corpus state, permission readiness, and recovery actions. |
| Operations | Work currently running. |
| Activity | Recorded work after it starts or completes. |
When something breaks, start in Status. When you want to change a control, open Settings.
Account
Section titled “Account”Account manages license state, organisation access, and purchased or sealed content where enabled.
Typical controls include:
- entering or restoring a license,
- connecting an organisation token,
- reviewing sealed pack activation,
- and checking account-level access for private registry content.
Credentials and tokens are stored in the local credential store.
General
Section titled “General”General contains installation and lifecycle controls:
- rerun Setup,
- update the app,
- configure helper startup,
- restart helper services,
- inspect local configuration paths,
- and manage local vault and runtime controls where those controls are user-editable.
The General page may show a compact health glance at the top. Detailed state still belongs in Status.
Providers
Section titled “Providers”Providers configures model routes. A provider card usually includes:
| Control | Purpose |
|---|---|
| API key | Enables a cloud or compatible endpoint. |
| Base URL | Points an OpenAI-compatible provider at a custom endpoint when supported. |
| Model selection | Chooses a model or tier for routing. |
| Reasoning or thinking level | Adjusts quality, latency, and cost where supported. |
| Test | Sends a small probe to confirm the route works. |
Provider access does not grant blanket vault access. A model receives only the context selected for a specific job and any plugin results permitted by policy and consent.
Plugins And MCPs
Section titled “Plugins And MCPs”Plugins connect Stallari to services. The MCP view shows installed plugins, contracts, credentials, readiness, and consent state.
Before a sensitive plugin can be used, Stallari should make clear:
- who published it,
- what data classes it can access,
- what action classes it can perform,
- whether network egress is possible,
- whether cloud model context may include returned data,
- and where to revoke consent.
First-party local corpus consent, such as Mail indexing, is a special data-class gate. Third-party plugin consent is broader and is handled per plugin.
Mac Permissions
Section titled “Mac Permissions”Stallari separates macOS grants instead of treating them as one checkbox:
| Permission | Meaning |
|---|---|
| Login Items | Allows the helper to run in the background. |
| Full Disk Access | Allows user-approved local corpus readers, such as Mail indexing, to read protected local data. |
| App Management | May be needed when macOS blocks app or helper replacement during update flows. |
| Plugin / MCP Consent | Authorizes a named plugin for specific capabilities. |
Settings owns the controls. Status owns live readiness and recovery prompts.
Privacy And Access
Section titled “Privacy And Access”Privacy controls define what Stallari should ignore, exclude, or require review for. Access Policy controls define what tools and actions are permitted under the current configuration.
Use conservative defaults for any source that contains legal, medical, financial, employment, or family-sensitive material. Review and approval gates are part of the product model, not an error condition.
Hot Reload And Restart
Section titled “Hot Reload And Restart”Many changes are picked up automatically. Provider keys, most plugin credentials, and privacy controls can usually update without restarting the helper.
Restart may still be required for lower-level changes such as helper lifecycle, local network serving, ports, or plugin runtime replacement. When restart is needed, Status or Settings should name the action plainly.
Related concepts
Section titled “Related concepts”- Legibility And Continuity — why controls live in Settings while live state lives in Status
- Local Vs Cloud — provider configuration is the user-facing edge of routing policy