bdibranding Help

bdibranding Privacy

Model provider and sign-in, public model and price list, connector, learning, update, storage, backup and website disclosures reviewed: 2026-10-10. Web search, code-running and computer-control disclosures reviewed: 2026-10-07. Other sections last reviewed: 2026-07-25, against the shipping code.

bdibranding is a local-first desktop app. It runs a small server (the "sidecar") on your own machine (localhost) and does the agent work there. There is no bdibranding cloud, no bdibranding account, and no bdibranding server that receives your data. This document is written in plain English and is grounded in an audit of the actual code — not aspirations.

Support questions: info@bdibranding.com.

The short version

What leaves your machine — and only these

bdibranding itself makes outbound network requests in exactly these situations. Nothing else. (A program an agent runs for you, such as a terminal command you let it run, makes its own requests; see section 10.)

1. Your chosen AI model provider (using your key)

When an agent runs, bdibranding calls the model provider you configured, authenticated with your API key or, in the developer version only, your sign-in (ChatGPT or Grok). Your prompts, conversation, and any content the agent works with are sent to that provider so it can generate a response — the same as any app that uses that provider. bdibranding is a pass-through here; it does not sit in the middle.

Depending on what you set up, that provider is one of:

The ChatGPT and Grok sign-ins are offered only in the developer version of bdibranding (run from its source code), not in the installed app, which neither offers nor uses them. Where one is used, it also asks that sign-in address for the code you confirm in your browser and, while you stay signed in, for fresh access tokens. The earlier Kimi sign-in was retired in every version: Kimi is reached only with your Kimi API key, and bdibranding names itself as bdibranding in those requests.

Your key, your data, your account. bdibranding never sees a bdibranding-owned copy — the key is yours and the request goes straight to the provider you picked.

2. Chat channels — only if you connect them

If you connect a chat channel, bdibranding talks to that platform to send and receive messages on the channel you set up, authenticated with the token (or endpoint) you provide. Nothing is contacted unless you connect it:

If you never connect a channel, bdibranding never contacts any of these services.

3. Spotify — only if you enable it

If you enable the Spotify integration and authorize it, bdibranding calls the Spotify API (api.spotify.com, accounts.spotify.com) to read what's playing and control playback, using the token you granted. If you don't enable Spotify, no Spotify requests are made.

4. Web search / web fetch — only when an agent uses that tool

If an agent uses its web tools, bdibranding searches through an independent service — Mojeek (mojeek.com, with DuckDuckGo as a fallback) — or, if you have an OpenRouter key, OpenRouter's web plugin. Page reading goes through Jina Reader (r.jina.ai) only if you have saved your own Jina key; with no key, or if Jina is unavailable or rate-limits, the page is fetched directly from its own host, so the site you asked to read may see the request come from your machine. The station's browser reader searches Bing (bing.com) and DuckDuckGo (duckduckgo.com), and loads pages directly in a headless Chrome on your machine, so those search engines and the pages' own hosts see the request. Only your search query or the URL you asked to read is sent, and only when an agent actually runs a web search or fetch. (The fetch tool also refuses to reach private/internal network addresses, as an anti-abuse guard.)

5. Voice — two different paths, and they behave differently

Spoken agent lines are made on your computer by the built-in Kokoro voice engine, and what you say into the microphone is transcribed on your computer by local Whisper or, on Windows, offline System.Speech dictation. None of it is sent anywhere. Cloud voices are off unless you turn them on in Settings → Live Voice. The built-in voice understands and speaks English only; for other languages, type your message, or turn cloud voices on. When they are on, spoken lines are sent to your configured model provider (OpenRouter, OpenAI, or Gemini), or to ElevenLabs (api.elevenlabs.io) when you configure an ElevenLabs voice; click-to-talk recordings are sent for transcription to Groq, OpenAI, or OpenRouter, whichever you hold a key for; and in a web browser, the browser's own speech recognition (which may send audio to the browser's maker) can be used. The local engines stay the backup. Audio files your agents make and voice messages from connected chat apps follow the same setting. Voices off means no TTS requests at all.

Hands-free Live Voice does not use a vendor realtime-voice session. Listening runs on local Whisper when installed; on Windows, offline System.Speech dictation can serve as the fallback. On those paths, your recorded audio never leaves your machine. The open Whisper and Kokoro weights may be fetched from huggingface.co on first use and cached in your user profile, in %LOCALAPPDATA%\ai.bdibranding.harness\models\ on Windows (an earlier version kept them in %LOCALAPPDATA%\bdibranding\models\; the app moves them across on first use, without downloading them again) or ~/Library/Application Support/bdibranding/models/ on macOS; that download carries no audio or transcript. Once cached, listening is offline. Speaking is offline too. If Kokoro is unavailable and cloud voices are off, replies are shown as text only.

6. A version check for updates (no personal data)

Automatic update checks are on by default, but no update address is configured in this release, so the desktop app's updater has nothing to ask and makes no network request; a manual check from the Update Center behaves the same way. You can stop the automatic checks by turning off AUTO-CHECK FOR UPDATES in SYSTEM > SETTINGS > APP & BACKUP (under UPDATES). If a release feed is added later, the request will be a plain GET for a small public update-manifest file — no user data, no identifier, and no telemetry are sent — each update's integrity will be cryptographically verified against a key baked into the app before anything is installed, and this page will say so before the app makes that request.

7. Public model and price lists (no personal data)

To know each model's context limit and real published price, whichever provider you use, bdibranding downloads two public lists as soon as it starts, with no action from you. Neither request carries your key, your prompts, or any account detail; the site you ask sees your IP address, as with any web request:

8. Connectors and saved API connections — only the ones you add

When you add an MCP connector, sign in to a Google service, or save a key for a service under ABILITIES → SAVED API CONNECTIONS (for example Meshy, for 3D models), bdibranding talks to that service: to connect and see what it offers, and whenever an agent uses one of its tools. Nothing is sent to a service you haven't added. Installing a skill from a web address you enter (ABILITIES → SKILL EXCHANGE) downloads that address (a GitHub file page is read from raw.githubusercontent.com), and for a GitHub address also asks api.github.com which version it points to; nothing of yours is sent.

9. Google Workspace — only when you connect an account

bdibranding's local connector calls the Google services you authorize, using the permissions you approve in Google's consent screen. Gmail, Drive, Calendar, Docs and Sheets are connected separately. Google also supplies the account identity shown with a connected service.

Use in agent work. Content returned by these tools can become part of the agent's conversation and requests to your chosen model provider. Local execution of the Google connector does not mean that Google-derived content remains exclusively on your device. The provider you choose has its own data-handling terms. Saved conversations, downloaded artifacts and agent memories may retain content from this work.

Credentials and disconnecting. Google sign-in credentials and connector configuration are stored under your local bdibranding workspace, including recovery copies, encrypted with AES-256-GCM under a key held in the OS keychain (plaintext only on a station with no key; see the storage table). Removing a connected service verifies removal of its saved configuration and credentials from the active state and its recovery copy before reporting success. This does not delete prior conversations, artifacts, memories or documents in Google, and it does not itself revoke bdibranding's authorization in your Google account. Manage or revoke that authorization separately through your Google account's third-party connections. Revocation stops future authorized access; it does not erase copies already saved locally or sent to a model provider. Delete those separately using the relevant app or provider controls.

10. Where agent code runs, and computer control — only if you use them

What the station learns about you

bdibranding learns from the work you do so it can suggest a next step and remember what matters to you. Learning is on by default. It is local: nothing here is sent to bdibranding. But notes about you that you keep (the beliefs in your dossier and the agent's most relevant kept memories) are included in every agent's instructions to your model provider, on every run, whether it starts in the window, from a chat channel or on the night shift. The model calls described next send to that provider too. You can pause it and you can wipe it.

What it learns. The topics you keep working on; a profile of which suggestions you accept or turn down; patterns in how you take over, keep or discard the station's work; drafts of routines and recipes built from those topics; and notes about you that agents propose after a run (memories, beliefs, study notes and open threads). Folders you have approved are also scanned on this machine for project ideas, with no model call.

After-run passes: what they send. When a run finishes normally the station can start short background model calls on its own: reflection (proposes memories), study (proposes updates to what the station believes about you), thread mining, a scout cycle (drafts a routine or recipe), skill review (how-to procedures, not notes about you) and, only when a developer setting turns on its model call, a daily skill curator that tidies saved skills. At most two start after a run by default. After a run that failed, a failure review can run. While INITIATIVE is above WAIT (or when you press REFRESH QUESTS), a quest refresh runs at least once a day, and sooner after your goals or quest progress change or when no quest is left open, sending your goals, your dossier, your recent activity and your topics. The app window makes model calls of its own as well, each carrying the agent's instructions and so your dossier: the first pitch after your first finished task, occasional suggestions after later runs, ideas for a new conversation, a plan of steps toward a goal you set (offered on its own a few seconds after a run, and it also sends that goal, your open threads and your recent activity), and standing-job offers. Each one sends short excerpts of the run's conversation or of those records, and for some of them the notes the station already holds about you so it does not repeat itself, to the model provider you configured, with your key. Anything a run read from the web or a connector can be inside those excerpts. Their cost counts against your spending limits. Nothing goes to bdibranding.

Where the results are stored. On the station's disk, in the files named in the table below, and in the app window's own browser storage and your saved station (the preference profile, work signals, recurring-task memory, suggestions, study state and the like). Both stay on your machine.

PAUSE LEARNING (Recruitment Bay, STATION FAMILIARITY) stops the recommendation profile and its ledger, the scout, folder discovery, topic tracking, failure review and the window's own suggestion generators (ideas, the first pitch, goal plans and standing-job offers). By default it also stops agents forming new beliefs about you: reflection after runs, study, thread mining, and the dossier and recent activity a quest refresh would send. (SETTINGS > PERMISSIONS > AGENT AUTHORITY AND CONSENT can limit the pause to the profile alone, which leaves reflection, study, thread mining and the quest evidence running.) These keep running while paused: anything you write yourself (dossier, goals, threads, projects), memory you already kept, and skill review, which still sends run excerpts to your provider. Pausing deletes nothing. A stop-everything command (/halt or E-STOP) also holds background learning until RESUME AUTOMATION. Reflection can be switched off on its own: agent dossier > MEMORY > REFLECTION ON.

FORGET (same panel, two presses) first stops any learning pass in flight. It then clears, on the station, the interest topics, scout drafts and state, night-shift learned weights, the recommendation history and its learned weights, and the learned workflow patterns, and in the window the preference profile, work signals, recurring-task memory, recruit picks, recommendation quality, suggestions, seeds, study state and understanding. It keeps what you wrote or decided (dossier, goals, open threads, projects, task history, agent memory, skills and quests) and what you refused, so the station does not ask again: the questions you waved off or answered no, the beliefs you discarded, the ideas you declined (the recommendation ledger keeps these as its shared declined list), the recurring-task suggestions you dismissed and the takeovers you said not to offer again. When it finishes it lists what it cleared and what it kept.

What bdibranding stores on your machine (and how)

Everything below lives under your per-user app-data directory (see the paths in "The short version" above for Windows/macOS/Linux). It never leaves your machine except as described above. Where this document says "OS keychain," that means Windows Credential Manager, the macOS Keychain, or the Linux Secret Service (e.g. GNOME Keyring), depending on your platform — always under the service name ai.bdibranding.harness.

What Where How it's stored
Conversation transcripts transcript-history-v2/ (a legacy transcript.jsonl is kept after it is imported) Plaintext JSON on disk
Run history + cost ledger runs.jsonl, ledger.jsonl Plaintext JSON on disk
Agent memory / beliefs / to-dos <agent>.notebook.json, <agent>.todo.json, dossier/goals Plaintext JSON on disk
Voice cache (spoken-line audio) voice-cache/ Plaintext audio files on disk
Discord / Telegram / Slack / Matrix tokens OS keychain (desktop) OS keychain (Windows Credential Manager); plaintext fallback in bare/dev mode — see below
Your model-provider API keys OS keychain (desktop) OS keychain (Windows Credential Manager); loaded into app memory at launch, never written to disk by the desktop app. In bare/dev mode they are plaintext in the app window's browser storage; a chat channel's copy in channels/secrets.json is sealed with the connector key, or held in memory only when there is none — see below
Spotify OAuth token .secrets/spotify.json AES-256-GCM sealed with the connector key (OS keychain on desktop); plaintext only when no key is available
ChatGPT / Codex sign-in token codex/tokens.json AES-256-GCM sealed with the connector key (OS keychain on desktop); plaintext only when no key is available
Grok sign-in token grok/tokens.json AES-256-GCM sealed with the connector key (OS keychain on desktop); plaintext only when no key is available
Kimi sign-in token an earlier version saved (that sign-in is retired) kimi/tokens.json Left exactly as that version saved it (AES-256-GCM sealed with the connector key, or plaintext where no key was available); the station no longer reads, uses or changes it
Google and other connector credentials, account identity and configuration connectors/state.json and its recovery copy AES-256-GCM encrypted on desktop, with the encryption key in the OS keychain; plaintext only if no key is available
Channel message history (Discord/Telegram chats the bot saw) channels/*.history.json Plaintext JSON on disk
Agent memory ledgers (accepted/declined memory proposals, dossiers, goals) per-agent *.json Plaintext JSON on disk
What the station has learned about you: interest topics, scout drafts, night-shift weights, recommendation ledger, workflow patterns, study state, folder-scan findings, the PAUSE setting scout.interests.json, scout.state.json, nightshift.learn.json, recommendations.json, workflow-takeovers.json, study.state.json, discovery.state.json, personalization.json Plaintext JSON on disk
The window's learning stores: preference profile, work signals, recurring-task memory, suggestions, seeds, study, understanding, questions you waved off The app window's own browser storage (keys starting bdibranding.), and the saved station for the profile and work signals Plaintext in that storage and in the station's save, on your machine
Station state (widgets, sub-agents, routing, quests, XP) various *.json Plaintext JSON on disk
Settings, roster, permissions, cron, connectors various *.json Plaintext JSON on disk

Secrets: keychain vs. plaintext — the honest picture

On the desktop build, your provider API keys and your Discord, Telegram, Slack and Matrix tokens are held in the OS keychain (Windows Credential Manager, under service ai.bdibranding.harness), not in a plaintext file. When you upgrade from an older build, any bot token found in the old plaintext channels/secrets.json is migrated into the keychain and stripped from that file.

If you instead run the bare sidecar directly (developer mode / node sidecar/index.js / tests), the OS keychain isn't reachable, so those bot tokens fall back to a plaintext file (channels/secrets.json and its .bak copy). The model-provider key a chat channel answers with (the app window hands it over when you connect the channel) is never written there in plain text: it is saved sealed with AES-256-GCM under the connector key when the sidecar has one (BDIBRANDING_CONNECTOR_ENCRYPTION_KEY), and otherwise kept only in the station's memory, so after a restart the channel's card asks you to press RESUME, which hands it over again. A plain copy an earlier version wrote there is sealed or removed when the station starts, and FORGET removes the key from both files. In that mode the app window also keeps your provider keys in its own browser storage. If you turn on Settings › PROVIDERS › BACKGROUND WORK there, the window also lends those keys to the station's memory, never its disk. While it is on, everything the station runs by itself uses them, as on the desktop app: routines, group chats, backup models, the model lists, sub-agents, and editors or tools that use the integration key. The station forgets them when it restarts or when you turn it off. This is called out plainly in the code rather than hidden.

Connector credentials and the ChatGPT, Grok and Spotify sign-ins use a separate encryption key under the same keychain service, account connectors:encryption:v1. Desktop startup encrypts and verifies both active and recovery copies before removing legacy connector credential files, and seals a sign-in an earlier version saved in the clear (both its main file and its backup). If the keychain is locked or the original key is missing, bdibranding preserves the encrypted files and reports that saved connections are unavailable; it does not replace them with empty data. Copies of those files alone cannot unlock connections on another OS account or computer, so protect and retain your OS credential store when restoring backups.

The Spotify OAuth token (.secrets/spotify.json) and the ChatGPT/Codex and Grok sign-in tokens (codex/tokens.json, grok/tokens.json) are sealed the same way, with AES-256-GCM under that connector key. They stay plaintext only on a station that has no key (a bare sidecar started without one, or a desktop launch whose keychain could not supply one); if that matters to you, keep those integrations off there. (Transcripts are run through a redaction step at write-time to avoid capturing secret-shaped tokens in your chat history, but the transcript file itself is plaintext.)

Everything the table above marks as plaintext sits in files under your user profile, so anyone with access to your Windows user account can read it. Protect your machine account accordingly.

What we do NOT do

Deleting your data

Your data is just files. To wipe it, uninstall bdibranding and delete the ai.bdibranding.harness app-data folders for your OS — Windows: %LOCALAPPDATA%\ai.bdibranding.harness\ (C:\Users\<you>\AppData\Local\ai.bdibranding.harness\, which holds your station and the app window's own storage) and %APPDATA%\ai.bdibranding.harness\ (settings and logs); macOS: ~/Library/Application Support/ai.bdibranding.harness/; Linux: ~/.local/share/ai.bdibranding.harness/. The desktop app keeps more outside those folders, so delete it as well. On macOS the app window's own storage, which holds a copy of your saved station, is ~/Library/WebKit/ai.bdibranding.harness/ (and ~/Library/Caches/ai.bdibranding.harness/ if present). On Windows the downloaded voice models are in %LOCALAPPDATA%\ai.bdibranding.harness\models\, so they go with that folder; an earlier version kept them in %LOCALAPPDATA%\bdibranding\, which also holds a station an earlier version kept there if it was never moved. On macOS they are in ~/Library/Application Support/bdibranding/. Provider API keys and channel tokens held in the OS keychain can be removed there too (search your credential manager / keychain for ai.bdibranding.harness).

On Windows the uninstaller offers two boxes. Back up my station before uninstalling (recommended) is ticked by default: before anything is removed it copies your station to Documents\bdibranding backups\station <date> and tells you where it went; if that copy fails, nothing is removed, the partial copy is cleared away and you are told why. It copies the station from every folder this or an earlier version kept one in (%LOCALAPPDATA%\ai.bdibranding.harness\workspaces, %APPDATA%\ai.bdibranding.harness\workspaces and %LOCALAPPDATA%\bdibranding\workspaces) and, when the delete box is ticked too, the earlier stations kept beside them (the ones START FRESH set aside, the pre-update snapshots and the copies a migration replaced). It leaves out saved sign-ins (the station's .secrets, codex, grok and kimi folders and an earlier version's connectors\oauth.json) and the channel settings file, which can hold bot tokens, so after restoring the backup you sign in and connect channels again. If your Documents folder syncs to a cloud service (OneDrive, for example), that copy syncs with it. Permanently delete my station removes both ai.bdibranding.harness folders above, voice models and earlier stations included. Saved provider keys and channel tokens stay in Windows Credential Manager either way. Updating the app never deletes or backs up anything.

Station backups are full copies of your station too (conversations, memories, routines and the rest). BACK UP STATION (SYSTEM > SETTINGS > APP & BACKUP, STATION BACKUP) saves one to Documents\bdibranding backups unless you chose another folder there, and the uninstaller's backup box puts its copy in that same folder. Uninstalling never removes it, so delete the backup files there yourself (and any copies you moved elsewhere) to remove them.

This website (ai.bdibranding.com)

The website you're reading is a static site with no accounts, no cookies, no analytics, and no tracking scripts. Two things are worth stating plainly:

Changes

If this changes, we'll update this document. Questions: info@bdibranding.com.