Endpoint behaviour disclosure

Every process we spawn, every port we open.

Bolt works on your machine, so the work is visible on your machine: it reads your screen, your clipboard and the files you point it at, and drives other applications for you. Everything it does to get that done is listed here, with the reason attached and the command to check it yourself. Behavioural tooling flags this class of application - Zoom, Loom, Raycast, Alfred and iTerm are flagged the same way - so the useful thing we can give you is not reassurance, it is the full list.

First, what never happens

Bolt runs on your machine.

We have no access to it, and no access to anything on it.

Sparcle is never in your data path.

Bolt does all of this on your machine so none of it has to leave. That's the trade this page documents - the list below is long because it's showing you local behaviour you can watch, instead of network traffic you can't.

No telemetry
No telemetry endpoint, no usage analytics, no crash reporter that phones home. Nothing counts what you do.
No licence server
The licence is a signed token, verified offline against a key compiled into the binary. Bolt never asks us whether you may run it.
No Sparcle server, anywhere
We operate no service that receives customer content. There is no copy to breach, subpoena, or ask us to delete.
The only connection Bolt makes on its own
An update check against our release channel on GitHub. Not a Sparcle host: github.com. Block it and Bolt keeps working, it just stops offering updates.
No administrator rights
Bolt never asks for root or administrator privileges, and nothing described on this page needs them. It also treats privilege escalation as dangerous in the other direction: with administrator privileges is on the explicit list of markers Bolt flags in caller-supplied AppleScript. The one exception is the optional network filter, which macOS requires an administrator to approve, and which is off unless you turn it on.
Everything else, only if you turn it on
Google Workspace or Microsoft 365 over your own OAuth, an LLM endpoint you choose, an optional one-time model download. Each goes from your machine to that provider directly. None of it transits us, because there is no us in the path.

1. Code signing identity

Apple Team ID
4VSW7NBZ2S, issued to Sparcle Inc. Every macOS binary we ship carries it.
Bundle identifiers
app.sparcle.bolt.enterprise for the application, and app.sparcle.bolt.enterprise.netfilter for the optional network filter system extension described below.
Binaries inside the bundle
Six, all signed, and all listed here so that an inventory tool's findings can be checked against ours: bolt, the application; bolt-api, the local API sidecar; bolt-ax, the Accessibility helper; bolt-ocr, the on-device text recognition helper; bolt-cli, the launch helper; and bolt-audit-verify, the standalone audit-chain verifier described at /trust/verify.
Windows
An SSL.com Extended Validation certificate issued to Sparcle Inc., with the key held in a cloud HSM. The installer installs for the current user and needs no administrator rights.
The network filter
Bolt ships a macOS network content-filter system extension. It is not active by default: activation is gated behind an explicit opt-in or an administrator policy, and a skipped activation is written to the log rather than passing silently. If you do not turn it on, it sits in the bundle and does nothing.
What the entitlements allow
No application sandbox; network client and network server; audio input for on-device dictation; and the restricted system-extension and network-extension entitlements that the filter above needs. Read them yourself out of the bundle rather than taking this row's word for it.

Verify the identity yourself before you trust anything else on this page. On macOS, codesign -dv --verbose=2 /Applications/Bolt.app should report an authority of Developer ID Application: Sparcle Inc. (4VSW7NBZ2S), a team identifier of 4VSW7NBZ2S, an identifier of app.sparcle.bolt.enterprise, and a stapled notarization ticket. For the Gatekeeper assessment use spctl -a -vvv -t exec /Applications/Bolt.app. An earlier version of this page printed -t install, which is the type for installer packages rather than application bundles, so anyone who copied it was running the wrong check. Verifying the download itself, including the signed release manifest and the software bill of materials, is covered at verify your download and supply chain.

If something in this inventory does not match what you observe on your own machine, that is the most useful message you can send us. Write to [email protected], or use the coordinated disclosure process. A gap between this page and reality is a defect in the page, and we will correct it.

2. Why we publish this

Why the signature does not answer this
Apple Developer ID, notarization, SSL.com EV, Google CASA. An EDR reads none of it. CrowdStrike, Defender, Santa, Netskope and Jamf Protect judge what a process does, so the signature answers a question your tooling is not asking.
Why the list is complete rather than curated
A process monitor shows you all of it in ten minutes. A partial list would be found out in the same ten minutes, so there is no version of this page worth writing except the whole one.
The last column
What your own tooling will show for that row, in the words it will show it in. Legitimate software and malware use many of the same operating-system mechanisms, which is why a behavioural alert needs a person to read it. This page is written for that person.
What this page does not claim
Not that every behaviour here is harmless. This is what Bolt does today: the work itself - reading the screen, the clipboard and files you point it at, and driving other applications - plus a handful of things macOS and Windows give us no other way to do. Each is disclosed with the reason attached, not because we are comfortable with it, but because you should be able to check it against what your tooling sees. If one does not clear your bar, tell us rather than passing quietly.
Scope
The desktop app on macOS, Windows and Linux. The self-hosted server is a different profile and is not described here. What leaves the machine is answered at /trust/for-your-it and /trust/network-allowlist.

3. Processes Bolt spawns

Grouped by what they're for. Some depend on your platform or your own setup, so not every row runs on every machine.

Screen, clipboard and on-screen content

Binary
Why it runs
When
What your tooling shows
screencapture
Captures the screen, a region, or one window id to a temporary PNG for the screenshot tool, the OCR bridge and the pixel-colour sampler. The screenshot tool checks the Screen Recording permission first and returns a permission error rather than capturing without it.
On a screenshot, OCR or pixel-sample request.
A console sees the system screenshot tool run.
powershell.exe
The Windows equivalent of the above: a GDI CopyFromScreen script, because Windows has no screencapture binary.
On a screenshot request.
A console sees PowerShell run a screen-copy script.
gnome-screenshot, spectacle, scrot, import, flameshot
The Linux equivalent. Bolt probes with which to find whichever one you have, and runs that.
On a screenshot request.
A console sees your desktop's own screenshot tool run.
bolt-ocr
A signed helper we ship inside the bundle. Runs Apple Vision text recognition against an image file already on disk. No network call and no model download; the pixels do not leave the device.
On an OCR request, and by the workers that read text out of an image when one is copied or saved.
A console sees a signed sibling binary launch inside the app bundle.
wl-paste, xclip, xprop
Linux only. Reads the clipboard's advertised MIME types to detect the KDE password-manager concealed hint, so that Bolt does not record a password manager's clipboard entry into history. It fails open: if nothing can answer, the content is treated as not concealed.
Automatically, as part of clipboard capture.
A console sees the clipboard's type list read.
bolt-ax
A signed helper we ship inside the bundle. Reads the macOS Accessibility tree: window titles, window geometry, the current selection and menu structure, and performs window and menu actions. Secure text fields are replaced with a redaction marker inside the helper before anything crosses back into Bolt. It exists so that Bolt does not have to drive System Events, which would raise an Automation prompt for every application.
On selection and screen-context requests and on launcher window actions, and automatically on every application switch when Accessibility has been granted. It is skipped silently when it has not.
A console sees a signed sibling binary in the app bundle read window information.

Desktop automation and script interpreters

Binary
Why it runs
When
What your tooling shows
osascript, reading
AppleScript and JXA against Mail to read messages, and against System Events to read the frontmost application. Calendar, Reminders and Contacts are not read this way: those go through EventKit and Contacts.framework, which send no Apple Events and are gated by their own narrower permissions - Calendars, Reminders and Contacts, each with its own system prompt - rather than by one Automation grant that would cover anything Bolt could ever ask that application to do. Contacts requires a search term and will not enumerate the whole address book.
On a request that needs that data. A background or speculative read refuses to spawn osascript at all unless the target application is already running, and defers rather than raising a first-time Automation prompt.
A console sees AppleScript run against Mail or System Events.
osascript, writing
The same interpreter, used to compose a mail message, send a reply, send an iMessage, respond to an invitation, and add attendees to an event. The last two stay on AppleScript because EventKit exposes attendees and participation status as read-only, with no public write API: it is the only interface macOS offers for them. Creating and updating events and reminders goes through EventKit. These are writes to your data and to other people.
Only on an explicit request. The macOS Automation permission and, for several of them, Accessibility, gate them first.
A console sees AppleScript send a message or answer an invitation, after the macOS Automation prompt.
osascript, arbitrary
Bolt exposes tools that run caller-supplied AppleScript and JXA. We are explicit internally that AppleScript can call do shell script, so this is arbitrary shell execution wearing a desktop-automation label, and it is excluded from every sandbox tier for that reason.
Off by default. AppleScript, JXA and PowerShell script execution must each be switched on by an administrator; no opt-in ships enabled.
A console sees AppleScript run text supplied by the caller. Nothing to see unless an administrator turned it on.
powershell.exe
Window management (raise, move between displays, snap, fullscreen, restore), enumerating windowed processes for the running-apps list, reading the foreground window, launching an application, extracting an application icon from an executable, and reading one entry from Windows Credential Manager.
On the corresponding action, and whenever the running-apps list refreshes.
A console sees PowerShell move windows and read one credential entry.
cmd
Hands a mailto or ms-settings URI to the default handler, and runs a caller-supplied command line for the terminal-execution tool on Windows.
On the corresponding action.
A console sees the Windows command shell run.
sh, /bin/sh
Runs a caller-supplied command line for the terminal-execution tool on Unix; runs the raw Exec line out of a Linux desktop entry, which can carry placeholders and arguments and therefore needs a shell; probes whether a search backend is on PATH; and runs a small detached relaunch script after a bundle rename.
On the corresponding action. The relaunch script runs at startup only when a rename actually happened.
A console sees a shell run.
gdbus
A generic D-Bus call tool on Linux, with a caller-supplied destination, object path, method and arguments.
Only on an explicit request.
A console sees a desktop-bus call you asked for.

Shell execution that Bolt injects, as opposed to what you type yourself, crosses a native gate before its bytes reach a terminal. The gate classifies the command line as safe, destructive or catastrophic; the default posture runs safe commands, requires explicit confirmation for destructive ones, and refuses catastrophic ones outright. An administrator can tighten it to confirm everything, or to refuse injected execution entirely. A surface with no way to ask you for confirmation is treated as unconfirmed and therefore refuses rather than proceeding. A command line carrying what looks like a live credential is escalated to require confirmation, so that a secret cannot be put on a command line silently. Every refusal and every confirmation is written to an append-only audit log as a fingerprint rather than as the command text. A command you type into the terminal yourself is never gated, by design.

Process, window and connection discovery

Binary
Why it runs
When
What your tooling shows
kill, taskkill
Terminates an orphaned bolt-api that still holds the port, after the name check above; and force-quits an application when you ask Bolt to quit it. On Windows the whole tree is killed, because a surviving grandchild can keep the inherited listening socket.
Automatically at startup for the sidecar; on demand for an application.
A console sees process termination initiated by Bolt.
wmctrl, xdotool, xprop
The Linux equivalents of the window work: list windows with their process ids and classes, resolve a window from a process id, position, resize, activate and gracefully close, and read the active window's name and process id.
On the corresponding action, and whenever the running-apps list refreshes.
A console sees window information read.
mdls
Reads an application bundle's size, last-used date and install date for the launcher's application info panel.
On demand.
A console sees an application bundle's metadata read.
sample, eu-stack
When the freeze watchdog detects a stall or a resource-ceiling breach, it samples process stacks to enrich the report. The target is always Bolt's own process id; it never samples another process.
Automatically, and only on a detected freeze.
A console sees Bolt sample its own process, and only its own.

Search, file discovery and opening files

Binary
Why it runs
When
What your tooling shows
mdfind
Spotlight. A filename-only lookup for launcher results, and a separate content search that is opt-in and scoped to the folders you configure as scan roots.
Query-driven. There is no background indexing sweep behind these.
A console sees a Spotlight query.
plocate, rg, where, recollq, tracker3
The filename and content search backends on Linux and Windows, used according to what is installed.
Query-driven.
A console sees a file search run through the index you already have.
qlmanage
Renders a Quick Look preview of a file you selected.
On demand.
A console sees a preview helper launch.
open, explorer, xdg-open, xdg-email, gtk-launch
Opens a file, folder, URL or mail draft in the operating system's own default handler, and reveals a file in Finder or Explorer. The hyphen-argument-injection guard - refusing a target that starts with a hyphen so it cannot be parsed as a flag by the spawned handler - exists in exactly one of these paths today: the browser-URL opener. File and application opens, revealing a file in Finder or Explorer, and the Linux mail-compose tool (which an LLM can invoke directly, with the recipient address as the unguarded value) each hand their target straight to the OS handler with no such check. See section 9.
On demand.
A console sees a process-launch chain from Bolt into the handler application.

Credential and secret store integration

Binary
Why it runs
When
What your tooling shows
bw, bws, op, vault, aws, az, gcloud, pass, keepassxc-cli, secret-tool, kwallet-query
Bolt federates the secret managers you already run rather than making a second copy of your secrets. Each of these is that vendor's own command-line tool, installed by you, not shipped by us. Reading a secret additionally requires that tool's own authentication, and a revealed secret is written straight to the system clipboard in native code rather than being returned across the application boundary.
Reading a secret is only on an explicit query or reveal. Detecting which tools are installed is not: today Bolt runs each installed tool's version command at app launch, again on every reconnect, and on TOTP host scans and unlock checks. That is more than detection needs and we are removing it, so that presence is determined from the filesystem without executing anything. Until that ships, expect these version commands at startup on a machine that has the tools installed.
A console sees your own vault tool run, under that tool's own authentication.
The availability probe
When the vault surface asks which providers are available, Bolt looks for each tool on your PATH by walking the directories in it and checking for an executable file. No process is started, so having a vault CLI installed does not cause Bolt to run it. A provider you never use is never invoked.
When the list of vault providers is requested.
Nothing. No process is started.

The local database, and preparing its binaries

Binary
Why it runs
When
What your tooling shows
postgres, initdb, pg_ctl, pg_upgrade, pg_controldata
Runs, initializes, stops and version-upgrades the local PostgreSQL cluster described in section 5. The stop path only acts if the process holding the port matches what our own postmaster.pid claims; otherwise it leaves it alone.
Automatically at startup, and on a detected version change.
A console sees a database server start under a desktop application. Section 4 explains why.
(no process - getxattr(2)/removexattr(2))
Bolt removes the com.apple.quarantine attribute from the PostgreSQL directory inside its own data directory, recursively, so the database it just extracted can execute. It is never done to your files or to the application bundle. It is two direct system calls rather than a subprocess, so nothing is spawned, but the attribute is still removed and we count that against ourselves.
On the first launch after the payload is extracted or upgraded, then skipped on every later launch.
A console sees an extended attribute removed from files inside Bolt's own data directory. Never from your files, and never from the application bundle.
codesign
Both macOS architectures receive a PostgreSQL payload we build ourselves, signed with our Developer ID and pinned in the binary to a digest that is checked before the bytes are used. Three read-only invocations run against the payload's own binaries: codesign --verify --strict, codesign -dv --verbose=2 to read the signing authority out of the signature, and codesign --verify --verbose=2 against the postmaster before the preparation is recorded as done. Their answer decides one thing, whether Bolt proceeds or stops. A payload that does not carry our signature is refused, and the install stops with an error naming the path.
On the first launch after the payload is extracted or upgraded, then skipped on every later launch.
A console sees a signature read against files inside Bolt's own data directory.
ldd
On Linux, reads the shared-library dependencies of the payload's own binaries so that a missing system library is reported as a clear message naming it, rather than surfacing as a database that will not start.
On the first launch after the payload is extracted or upgraded.
A console sees a dependency read against files inside Bolt's own data directory.

The PostgreSQL payload arrives signed with our Developer ID and pinned in the binary to a SHA-256 digest that is verified before a single byte is unpacked. A payload that does not match the pin is not used. It is already linked against its own libraries and already carries our signature, so it is extracted and run exactly as it left our build. Bolt reads its signature and acts only on the answer: a payload it did not sign is refused, and the install stops with an error naming the path. The installer served from this site does the same, and verifies the same pin before it writes anything. The quarantine attribute is handled the same way: Bolt probes for it first and strips only what actually carries it. On the payload we ship, nothing does, so on an ordinary install the strip does not run at all.

Trust, permissions and system state

Binary
Why it runs
When
What your tooling shows
security
Reads the login keychain to find out whether Bolt's local certificate authority is already trusted, and removes a superseded one. Three subcommands run: find-certificate, verify-cert and delete-certificate. Installing the authority is not a subprocess: macOS grants trust through SecTrustSettingsSetTrustSettings and Windows through CertAddCertificateContextToStore, both in-process, and both raise the operating system's own consent prompt before anything is trusted. Bolt does install a local certificate authority, and section 6 covers it in full, including how to inspect and remove it.
See section 6.
A console sees the login keychain read for Bolt's own local authority. Section 6 covers this in full, including removal.
systemextensionsctl
Read-only. The only call site that runs today is the bundle-rename guard: before renaming its own app bundle, Bolt asks whether its network-filter extension is staged, and declines the rename if so, to avoid orphaning it. A failed probe is treated as absent (no extension), not unknown - refusing every rename on a machine where the tool is merely slow or missing would be worse than proceeding. A continuous status-refresh path also exists in the source, but nothing calls it: the module's own doc says the settings surface that would wire it in has not shipped yet.
Only when a bundle rename is about to happen, which is rare - not on every ordinary startup.
A console sees a read of the system extension database, on the rare occasion a rename triggers it.
fdesetup
Reads FileVault status by absolute path, so that a binary planted earlier on PATH cannot answer for it. Needs no administrator rights.
Automatically, on window focus. A successful answer is cached for the life of the process, because changing FileVault requires a reboot.
A console sees FileVault status read.
defaults, networksetup, loginctl, gsettings, brightness
The Finder hidden-files toggle; the Wi-Fi power toggle; log out; the GNOME dark-mode setting; and display brightness.
Only as launcher actions you invoke.
A console sees a launcher action you took.
update-desktop-database
Refreshes the Linux desktop-entry cache after Bolt writes its own .desktop file to register the OAuth deep-link URL scheme, so the OS picks up the new handler.
Automatically, on every Linux startup - unconditionally, as part of app setup, not only when you invoke a launcher action.
A console sees a desktop-cache refresh run at every launch, not tied to anything you clicked.
codesign
The exact invocation is codesign --verify --strict against the app bundle. It answers one question - does this build's own signature verify - used only to explain a sidecar launch-failure crash on the splash screen when one occurs. It is not used to detect a stale Accessibility grant: that heuristic looks only at the running executable's own path - a dev-swap staging path, or an install outside the canonical bundle - and never calls codesign.
Only when the sidecar fails to start and Bolt is diagnosing why.
A console sees a signature read, on the rare occasion a launch failure triggers it.

Programs you configure

What
Why it runs
When
What your tooling shows
MCP servers
Whatever command you configure. Bolt spawns a Model Context Protocol server over standard input and output when you add it and mark it as running on this device. Typically a Node or Python entry point.
Only after you add it.
A console sees the server you configured run.
Coding-agent CLIs
Third-party agent binaries hosted over a stdio protocol. The built-in roster names devin, claude-agent-acp, codex-acp and gemini, none of which we ship; the roster is extensible from a file in your home directory, so an administrator can add others. A readiness probe runs the agent's own authentication-check command so the interface can tell you to sign in.
On selecting an agent, and when the interface evaluates which agents are ready.
A console sees the agent binary you installed run.
User Apps, the ones we ship
Twenty-eight command definitions written by us, shipped inside the signed bundle and copied into Bolt's data directory on launch, enabled by default. They are ours, not yours, and they are listed by name in the panel below this table. The feature is named for the fact that you can add your own, which is a different statement from the one an earlier version of this page made.
The command itself runs only when you invoke that App from the launcher and press Enter. Separately and automatically, a detection probe runs the tool's own version and authentication-status commands, so the launcher can hide an App whose tool you do not have.
A console sees the command behind the launcher entry you invoked.
User Apps, the ones you add
The same loader, pointed at any manifest you or your administrator drops in the same directory. The safety properties are the same for both halves: the loader rejects a command template containing a shell metacharacter, arguments are substituted into argv slots rather than into a command line, and the command line is never handed to a shell for interpretation. Some Apps, ours included, run a bundled shell or Python script as their program, which is an argv-only spawn of the interpreter and not the same thing as shell interpretation of the template.
As above.
A console sees the command you or your administrator defined.
git, docker
Read-only enumeration with a fixed argument list, to populate launcher autocomplete: branch and tag names, container and image names. You cannot influence the arguments, only the working directory.
While typing in the launcher.
A console sees a fixed read-only query against a tool you installed.
tmux
Lists panes across your tmux server and Bolt's own private one, with a captured tail of each, and can focus, kill or send keys to a pane. Sending keys crosses the command governor described above; focus and kill carry no command line.
When the tmux launcher scope is open.
A console sees tmux listed or driven.
bolt-cli
A signed helper we ship inside the bundle. Launches an application or opens a document while holding the launch assertion open, which is what makes strictly-managed applications start reliably without blocking the launcher.
Only when you open an application or document from the launcher.
A console sees a signed sibling binary launch inside the app bundle.

MCP servers and coding-agent binaries genuinely are yours: the executable is whatever you or your administrator named, so the table above describes the mechanism rather than the programs. They are spawned from your configuration and are not routed through the command gate, because that gate classifies command lines and these are program invocations. User Apps are the opposite case, and an earlier version of this page got it badly wrong.

The User Apps we ship, enumerated

Bolt ships twenty-eight User Apps inside the signed bundle and copies them into your data directory on launch, with the feature enabled by default. They are ours rather than yours, so they are enumerated here in full rather than described as user content.

A vendor CLI you installed
=gh-prs, =gl-mrs, =aws-s3, =k8s-pods, =okta-apps, =pd-incidents, =sf-orgs, =slack-auth, =stripe-products, =twilio-numbers, =vercel-deploys, and =service, which fans several of them out for one service name. Each runs that vendor's own command-line tool, under your existing sign-in, and the network call is theirs rather than ours. If the tool is not installed the App does not appear.
git, on a repository you name
=gitstatus, =gitdiff and =git-log. Read-only: status, a working-tree diff against HEAD, and a commit list.
Files in your own folders
=recent lists recently modified files across Downloads, Documents and Desktop; =shots lists today's screenshots on the Desktop; =md renders a Markdown file you point at; =note appends to a notes file and searches it; =expense appends a line to an expenses file and reads recent ones.
Nothing at all beyond the process
=scrub-pii, =parse-app-logs, =vendor-csv-cleanup and =incident transform text you paste in, on the device, with no file and no network access. They are the easiest ones to audit and the least interesting.
A service on your own loopback
=ollama reads a local Ollama model server on 127.0.0.1; =cdp-tabs reads the tab list from a Chromium you started yourself with a remote-debugging port open on loopback. Neither reaches off the machine.
A registrar, over the network
=whois runs the system whois binary against a domain you type. It is the one App whose whole purpose is an outbound query to a third party, and it carries no credentials.
The local machine itself
=sys, the system overview. It reads local system information; the detail of what it reads is disclosed separately.

Check the list rather than trusting it. The shipped copies are at Bolt.app/Contents/Resources/sample-user-utils/, and the seeded copies are in the user-utils folder of Bolt's data directory. Both are plain YAML, so ls gives you the count and any text editor gives you the exact command line each one runs. Read the seeded folder rather than the bundle if you want the truth about a particular machine: it holds whatever a previous version seeded and anything you or your administrator added, so its count is legitimately higher than twenty-eight on a long-lived install. Your own build is the authority here, not this list.

What they reach for. Most wrap a vendor command-line tool you already installed and signed into, so the network call is that vendor's own, made by their binary under your credentials: GitHub, GitLab, AWS, Kubernetes, Okta, PagerDuty, Salesforce, Slack, Stripe, Twilio and Vercel. Three reach the network without a vendor tool: =whois queries a registrar through the system whois binary, =ollama talks to a model server on your own loopback, and =sys can reach the network in one specific mode, disclosed separately. Nothing here routes through a Sparcle host.

They do not run on their own, and here is what that is worth. An App's command runs when you type its chip in the launcher and press Enter. The launcher shows a confirmation row first, worded by the manifest itself, so you can read what a given App will say in its YAML before you ever open Bolt. Setup guidance is display-only by design: where an App tells you to run a sign-in command, Bolt renders it for you to copy and never executes it, and the source says so at the type that carries it. Three qualifications, because the sentence above is worth less if we let it sound bigger than it is. The manifest format does allow an App to declare that it dispatches without that confirmation row, on a pattern match against what you typed. None of the twenty-eight we ship declares it, which you can confirm by searching the YAML for auto_when, but one you or your administrator add could. Then two things that are simply automatic. First, the detection probe: when the launcher first loads, when the Detected CLIs or User Apps settings section opens, and on an explicit rescan, Bolt runs each App's version command and its declared authentication-status command, eight at a time. That is a real spawn of a real vendor binary without you asking for that App. Second, seeding: the shipped manifests are copied into your data directory on launch and refreshed when we ship a better version, though a copy you have edited is preserved rather than overwritten. An administrator can switch the whole feature off, which stops both the probes and the invocations.

4. Ports and sockets

Whether a listener is bound to loopback or to every interface is the single most important fact on this page, so it is stated per port rather than in a summary sentence.

Port
Process
Bind address
Off-box
Authentication
13017
bolt
127.0.0.1
No
A per-install bearer token, generated on first launch into local-api.key at mode 0600. A request from one of Bolt's own pinned origins is admitted to ordinary app routes without it, but that is a WEAKER tier and it deliberately cannot reach saved logins, TOTP codes, the vault or the secrets provider: an Origin header is asserted by the caller and any local process can set one, so it is treated as a hint, never as proof. Those credential routes require the token itself. Only the health endpoint is reachable without either.
13018
bolt-api
127.0.0.1 or ::1
No
Session cookie, HttpOnly and Secure. The desktop build refuses to start at all on a non-loopback address; see the note below.
13020
bolt
127.0.0.1
No
The relay that lets a coding-agent command-line tool route through Bolt's masking. The listener is created only when the feature is enabled: with the feature off there is no socket at all, so a port scan finds nothing rather than finding a listener that refuses. Disclosed with a caveat below about what still authenticates a caller.
15432 to 15441 (Windows only)
postgres
Unix socket on macOS and Linux; 127.0.0.1 and ::1 on Windows
No
On macOS and Linux there is NO TCP socket. PostgreSQL is started with an empty listen address, so nothing binds a port at all, and it is reached only through a Unix socket inside a directory only your account can open (mode 0700). The single access rule is peer authentication: the kernel tells PostgreSQL which account connected, and that is the credential. There is no database password to steal, and no port to scan. On Windows PostgreSQL has no Unix-socket transport, so a loopback TCP port in this range and a password remain unavoidable there; that is a property of PostgreSQL, not a choice we made. Verify it yourself: on macOS or Linux nothing Bolt-related should appear in a TCP listener list for this range.

Nothing binds 0.0.0.0. On the desktop build this is enforced rather than configured: before any listener is created, the sidecar checks that its configured host is a loopback name and that it is running in desktop deployment mode, and exits with an explanatory message if either is false. The check exists so that a copy of the sidecar extracted from the application cannot be pointed at a network interface and used to serve other people. The server build, which is a different binary you deploy behind your own ingress, deliberately does not carry this restriction.

Fallback ranges, and why a port number is not an identity. Both HTTP services auto-discover the next free port when their default is taken: 13017 through 13026 for the first, 13018 through 13027 for the second. Those two ranges overlap across most of their length, so on a machine where the defaults were already occupied you can legitimately observe either of those two services on a port that is not the one in the table above. The gateway is different and worth stating separately: its port is a fixed constant with no fallback at all, so 13020 is the only port it will ever use. If something else already holds 13020, the gateway logs the failed bind and does not listen anywhere. Do not go looking for it further up the range. PostgreSQL separately takes the first free port from 15432 through 15441 when its cluster is created, and thereafter reuses whatever port that cluster recorded in its own start-up options file, so a long-lived install is often not on 15432. The practical consequence for a reviewer: match on the process and the bind address, not on the port number. The bind address is the part we are asking you to hold us to.

The gateway. Port 13020 is a relay that lets a coding-agent command-line tool send its traffic through Bolt, so that structured PII and secrets are masked before the request leaves the machine. No listener exists while the feature is off: the socket is bound when you switch it on and released when you switch it off, so a port scan of a machine that is not using it finds nothing on 13020. When it is on it binds loopback only, and a request must present this device's own Bolt credential.

Read what it is for precisely: it reduces what an agent sends when the agent is pointed at it. Pointing an agent at it is a line you export. Bolt does not stop an agent from talking to a model provider directly, and you should not deploy it as though it did.

Verify it yourself, and please do. On macOS or Linux, run lsof -nP -iTCP -sTCP:LISTEN and filter for bolt and postgres. On Windows, run netstat -ano and match the process ids. Every row should show a loopback address. Anything that does not is a finding we want reported to [email protected]. There is a fuller walkthrough at prove it yourself.

5. The database on your endpoint, and why

What ships
A PostgreSQL 18 payload, as a compressed archive inside the signed application bundle. On first run it is extracted into Bolt's own data directory and a cluster is created there. A database server running on a laptop is unusual, and we would ask about it too.
Why it is there
Bolt's memory and retrieval layer needs real relational and vector queries over data that must never leave the machine. The alternatives were to ship a weaker embedded engine, or to put that data in a service we operate. We are not willing to do the second, because the whole architecture rests on there being no Sparcle system in your data path. So the database runs where the data already is.
What can reach it
Loopback only. The cluster is created with PostgreSQL left at its default listen address, which is localhost, and Bolt connects to 127.0.0.1. It is not exposed to your network and it is not a service anyone else can reach.
How to verify that
Run the listener command in section 4 and confirm the postgres rows show 127.0.0.1 and ::1 rather than a routable address. Then try to reach that port from another machine and confirm it refuses. You can also read the cluster's own recorded start-up options file inside the data directory, which holds the exact argument list the server was started with, including its port.
Credentials
A password generated per cluster and stored in a credentials file at mode 0600 under your account. It is not a shared or default password, and it is not the same on two machines.
The preparation step
The payload is extracted and used as shipped. Nothing about it is rewritten, re-signed, or stripped of a quarantine attribute: it was signed by us before it left our build, and its digest is verified before use.

6. The optional local certificate authority

This is the disclosure most likely to stop a review, so it gets its own section, the exact commands, and the removal instructions.

What it is
Bolt can install a local certificate authority, generated on your machine and unique to it, into your user trust store. Its subject is Sparcle Local Development CA. It signs one short-lived certificate for localhost and 127.0.0.1, which is what Bolt's own listeners present.
What it is for
So that an external browser and the browser extension get a warning-free HTTPS connection to Bolt on loopback, and therefore HTTP/2. Without it those connections either warn, or in the extension's WebSocket case fail in a way that is difficult to diagnose.
What it is not needed for
The application window itself. That window already reaches Bolt over HTTPS with HTTP/2 whether or not the authority is installed, because the embedded web view accepts the certificate Bolt presents through an application-level handler scoped to loopback host names only. We would rather tell you that handler exists than have you find it: it means the in-app window does not perform default system trust evaluation for localhost, 127.0.0.1 and ::1, and it means Bolt works fully with this entire feature declined.
The exact command, macOS
No command. The certificate is added and trusted through SecTrustSettingsSetTrustSettings, called in-process against your login keychain - not the System keychain, so it needs no administrator rights. The scope is SSL-only, and macOS raises its own authorisation prompt, which you can cancel. Removal uses the command line - see below - because that is what you run, not what Bolt runs.
The exact command, Windows
No command. The certificate is added through CertAddCertificateContextToStore, called in-process against the current user's Trusted Root Certification Authorities store - not the machine store, so it needs no administrator rights. Windows raises no prompt for a user-store root, so the decision is Bolt's to disclose rather than yours to approve - which is why it is stated here.
Linux
Not implemented. Bolt installs no certificate authority on Linux at all.
When Bolt asks
Be precise about this one, because it is not simply opt-in. On a normal first run it is presented as a step you can decline with a click, and a decline is recorded permanently and never asked again. Outside that sequence, on macOS and Windows, Bolt will attempt the install during start-up if the authority is not already trusted and you have not previously declined; in that case the prompt you see is the operating system's own, and cancelling it is the decline. Bolt also re-attempts the install when the authority is rotated. We would rather describe it this way than call it purely opt-in, because a reviewer watching a start-up would otherwise see an attempt they were not told about.
How to remove it
Bolt does not remove it for you, and you should know that. On macOS, open Keychain Access, select the login keychain, find Sparcle Local Development CA and delete it. On Windows, run certmgr.msc, open Trusted Root Certification Authorities for the current user, and delete the same entry; or use certutil -delstore -user Root with the authority's thumbprint. The two platforms answer differently after that. On macOS, Bolt asks the live trust store on every check rather than trusting its own cache, so a removal is believed immediately and the feature simply reverts to warning in external browsers. Windows has no equivalent live probe yet - that code path deliberately answers "don't know" rather than guessing - so Bolt falls back to whatever it last cached: a removal via certmgr.msc is not picked up until something else gives Bolt a reason to re-derive the answer, such as the authority being rotated. Until then Bolt keeps reporting the authority trusted even though the store no longer has it. We would rather say that than let a Windows reviewer assume the two platforms behave the same.
One more thing we should say
If the authority's subject name changes between versions, a new authority is generated and offered, and the previous one is left in your trust store rather than being deleted. That is a deliberate choice, because deleting by subject name would also delete the replacement, but the consequence is that a long-lived install can accumulate more than one inert Sparcle authority. If you find two, that is why, and both can be removed by the steps above.
Blocking it entirely
If your policy forbids user-store root certificates, enforce that and deploy Bolt anyway. On Windows, Group Policy blocking additions to the user Root store makes the attempt fail and Bolt continues. Nothing in the product requires it.

7. Permissions Bolt asks for

The operating system permissions Bolt requests, what each is used for, and what stops working if you deny it, are already published as section 3 of the review packet. Rather than keep a second copy that can drift out of step with the first, that table stays the one place it lives: read it on the review packet page. All of them are optional, and Bolt runs without any of them.

Three things relevant to this page are not on that table. First, macOS Automation, sometimes called Apple Events: it is what the AppleScript rows in section 3 require, it is requested per target application by macOS rather than by us, and declining it disables those readers and writers only. Second, the network content-filter system extension described in section 9, which is inactive unless explicitly enabled. Third, nothing on this page requires administrator or root privileges at any point, including the certificate authority in section 6 and the database in section 5.

8. Files and directories Bolt writes

Where
On macOS, the application support directory named app.sparcle.bolt.enterprise under your own home directory. Equivalent per-user locations on Windows and Linux. Everything below is inside it, under your own account.
Encrypted databases
Clipboard history, the launcher and file index, alerts, thumbnails and the on-device vector indexes, as SQLCipher databases at mode 0600, each keyed by its own subkey derived from one device master. Connector credentials and OAuth tokens are encrypted with AES-256-GCM. On a signed release build the device master is held in the OS keychain - and a copy of it is also kept in this directory at mode 0600 as a recovery file that is not deleted, which on any build that is not a notarized release is the primary store. Anyone who can read this directory can read these databases. That is why the FileVault or BitLocker recommendation below is not boilerplate.
Key material
Several 64-byte key files at mode 0600: the local API bearer token, the session and token keys, and the device key, each 32 bytes of OS entropy hex-encoded into a 64-character file. The PostgreSQL cluster password file is a different size: one UUID's worth of randomness, hex-encoded to 32 characters, so it carries half the entropy of the others. On Windows these get an explicit restrictive ACL instead of a Unix mode.
The PostgreSQL cluster
A data directory at mode 0700 containing the local database, plus the extracted PostgreSQL installation. Memory record content inside it is sealed with authenticated encryption; a small queryable surface stays in clear text so local search works without decrypting everything.
The local certificate authority
The authority certificate and its private key, owner-only. Anyone who can read that private key can mint a certificate your machine trusts for localhost, which is the reason it is owner-only and the reason section 6 exists.
Models you opted into
On-device model directories, present only if you enabled the feature that downloads them: the PII detection model, the visual-search model, and the speech-to-text model.
Logs and state
Application and sidecar logs, window state, configuration, and the freeze reports produced by the watchdog. Logs can contain file paths and application names. They are local files; nothing ships them anywhere.
Not stored by us
None of this exists on any Sparcle system. There is no copy to subpoena, breach, or ask us to delete.

9. Hardening, and how to see it

What we will and will not put on a public page, and how to get the rest.

Where the hardening list lives
Bolt has an internal hardening backlog and it is worked continuously. What it does not have is a public list of unfixed weaknesses with enough detail to act on: naming an open weakness precisely, on a page anyone can read, arms whoever reads it first. Everything on this page describes behaviour that ships today and can be verified today.
How to get the specifics
Under an NDA, and gladly. If you are evaluating Bolt and want the current hardening backlog, the reasoning behind each item, and what it is scheduled against, ask and we will share it with your security team directly. That is the version of this conversation where detail helps you and does not help anyone else.
Independent testing
Bolt is undergoing an external penetration test and source-code audit. We commissioned it to be published rather than filed, so what it finds will be readable by you rather than summarised by us.

Where the platforms differ

Most of this page describes behaviour that is the same everywhere. Protection of the local database and its keys is not, and the differences are large enough that a Windows reviewer should not infer macOS properties. What follows is the ceiling each platform allows, not a claim about what ships today - the socket and operating-system-identity work described here is in progress, and section 9 tracks it.

The database transport
macOS and Linux: PostgreSQL can be reached over a Unix domain socket in a private directory, so no network port exists at all and the operating system decides who may connect. Windows: PostgreSQL has no Unix-socket transport, so a loopback TCP port and a password are unavoidable there. This is a property of PostgreSQL on Windows, not a choice we made, and we cannot engineer around it.
The database credential
macOS and Linux: with a socket, PostgreSQL can authenticate by the operating-system identity of the connecting process, so no password needs to exist on disk. Windows: a password is required. It is protected by an owner-only access-control list with inheritance removed, which is the Windows equivalent of owner-only file permissions.
Where encryption keys live
macOS: the Keychain. Windows: the Credential Manager, encrypted per user by DPAPI. Linux: the Secret Service, if your desktop provides one. On a headless Linux machine there is no Secret Service, and keys fall back to a file in the data directory. That is the weakest of the three and we would rather say so than let it be discovered.
Restricting key access to Bolt itself
macOS is the only one of the three where the operating system can check which application is asking. A Keychain item can be bound to a code-signature requirement, so a different binary running as the same user is refused. Windows and Linux have no equivalent at the credential-store layer. This is a real difference in what we can promise per platform.
The limit that applies everywhere
On all three platforms, a process running as you can read what you can read. File permissions separate users; they do not separate programs running as the same user. Everything above narrows that, and none of it removes it. Administrator or root access defeats all of it.

FAQ

Questions a reviewer actually asks

Does anything about me, my machine, or my data reach Sparcle?
No. There is no telemetry endpoint, no usage analytics, no crash reporter that phones home, and no licence server. The only connection Bolt makes on its own is an update check against our release channel on github.com - not a Sparcle host. We operate no service that receives customer content, so there is no copy of your data to breach, subpoena, or ask us to delete.

Can an attacker use Bolt to reach something they could not reach without it?
This is the right question to ask, and it is the one we hold ourselves to. Bolt holds Accessibility, Automation, file access and shell execution, and exposes them behind loopback listeners, so the honest threat model is a local process rather than a remote one - loopback alone is not the answer. Sensitive routes require a per-install bearer token stored at local-api.key, mode 0600. Hardening of the local listeners is ongoing work rather than finished work, and we will walk your security team through the current state of it directly.

Does Bolt need administrator or root privileges?
No. Bolt never asks for them, and nothing on this page needs them. It also treats escalation as dangerous in the other direction: with administrator privileges is on the explicit list of markers Bolt flags in caller-supplied AppleScript. The single exception is the optional network filter, which macOS requires an administrator to approve, and which is off unless you turn it on.

Can any of these listeners be reached from the network?
No. Every listener binds 127.0.0.1 or ::1, never 0.0.0.0. You should not take that on our word - the ports section names each one, and you can confirm every binding on your own machine with the commands there, or with any process monitor.

Why does my EDR flag Bolt?
Because in order to help you with everything you have, Bolt reads your screen, your clipboard and your files, and drives other apps for you. That is how it gets things done for you. Behavioural tooling flags the whole class of application that works this way - Zoom, Loom, Raycast, Alfred and iTerm are flagged for the same reasons - and a finding like that needs a person to read it, not just a machine. The tables below name every one of them, with the reason and the moment it happens, so a flag you see can be matched to a line here rather than investigated blind.

Does Bolt install a root certificate, and can I prevent it?
It can, and you can. It is a locally generated authority that signs one certificate for localhost, so browsers and the Bolt extension get warning-free HTTPS. Be precise about how it is offered: on a normal first run it is a step you can decline, and a decline is permanent. Outside that sequence Bolt will attempt the install at start-up if it is not already trusted and you have not previously declined - in which case the operating system's own prompt is the consent surface. Administrators can switch it off entirely with the AllowLocalCertificateTrust policy key, which defaults to off on a managed device. The exact commands to inspect or remove it are in the certificate section.

What happens if I deny every permission?
Bolt runs. Every operating-system permission it asks for is optional, and each one removes a capability rather than breaking the product. The permissions table says exactly what stops working for each.

What runs automatically, and what only runs when I ask?
Every row in the process tables says which it is, in its own column, because it is the question that matters most and the one easiest to answer vaguely. Where something runs automatically that only needs to run on demand, the row says so plainly rather than rounding it down.

What is the worst case if Bolt itself is compromised?
It runs as you, without administrator rights, so the blast radius is your user session rather than the machine. But that session is a real prize: Accessibility, Automation, your clipboard, your screen, your indexed files, and shell execution. Two things limit it. Nothing is reachable from the network, so an attacker needs local presence first. And there is no Sparcle-side copy of anything, so there is no second target and nowhere for data to be exfiltrated to by us. We are not going to pretend the footprint is small; we would rather you size it accurately.

Can I verify any of this myself rather than trusting the page?
Yes, and you should. Nothing here is a claim you have to take on faith: every process, port and path on this page is observable with a process monitor and a few commands in about ten minutes. Where a claim can be checked with a specific command, that command is printed next to it. If something on your machine does not match what this page says, that is a defect in the page and we want to hear about it.

Can I deploy Bolt to a managed fleet and lock the settings?
Yes. macOS configuration profiles and Windows Group Policy, with settings pinned so users cannot change them, and a browser extension that can be force-installed. Managed deployment is documented separately at /trust/managed-deployment.

Why publish this level of detail at all?
Because you can observe all of it in about ten minutes with a process monitor, so the only question is whether you find it with the reasons attached or without them. A reviewer who reads what a behaviour is for, and when it happens, can make a decision. A reviewer who finds the same behaviour undocumented has to assume the worst. We would rather be checked than believed.