Skip to main content
px0 is local-first: your workflows, guidelines, brain, and run history are files on your disk, and there is no px0 server, account, or hosted state. But local-first is not the same as offline, and “your data is safe” is not a useful thing for documentation to say without specifics. So here is every place data goes, and what you control.

​
px0 itself sends nothing

px0 has no telemetry, no analytics, and no crash reporting. It does not phone home, and there is no account to associate anything with. The only network requests px0 makes on its own behalf are: Turn the update check off entirely if you would rather it never ran:

​
Prompts go to your model backend

This is the significant one, and it is worth being precise about. px0 has no model of its own. Every workflow run, every px0 brain ask, and every model pass inside px0 workflows new shells out to your coding agent CLI - claude -p by default - which sends the prompt to whichever provider that CLI is signed into. What is in that prompt:
  • The workflow body, after templating.
  • Every guideline file the workflow lists, inlined verbatim.
  • Every resolved input: tool results, retrieved brain passages, piped stdin.
In other words, the prompt is the union of the context the workflow gathered. If a workflow reads your calendar and your inbox, that content is in the prompt. Two consequences worth internalizing: Your provider relationship is with the harness CLI, not px0. px0 never asks for, stores, or transmits a provider API key. Whatever data-retention terms apply to your claude, gemini, pi, or opencode login apply here. If you need a different arrangement, change the harness rather than looking for a px0 setting. You can see the exact text that was sent. Every run records its rendered prompt, and the run browser shows it:
That is the ground truth. If you are unsure whether something reached the model, read the prompt rather than reasoning about it.

​
Most tool calls go through Composio

Curated, discovered, and user-declared toolkit calls route through Composio, including the curated GitHub tools - those use Composio’s authenticated proxy rather than calling GitHub directly. So a tool call carries its arguments to Composio, and Composio carries them to the app. What that means in practice:
  • App credentials never touch your disk. px0 holds a Composio API key and connected-account ids, not your Slack or Gmail tokens. Revoking access happens in Composio or at the provider, or with px0 tools disconnect.
  • Authorization is per app, and you drive it. Nothing is connected until you complete a browser consent, and px0 only ever prepares authorizations for apps a workflow actually needs.
  • Write tools are surfaced everywhere. The builder names them before generating a workflow, --dry-run stubs them, and px0 runs marks any run that used one - so “what has px0 sent on my behalf?” is an answerable question.

​
Local tools skip Composio entirely

file.read, file.write, file.list, brain.add, and shell.run run directly on this machine and never touch Composio at all. http.get and http.post reach whatever URL a workflow gives them directly, the same way px0 brain add does. shell.run stays off until tools.allow_shell is explicitly set, and a workflow that can run a shell can do anything you can - treat enabling it the way you would treat handing a script your own shell.

​
What stays local, always

brain/work/ is a hard exclusion, not a ranking penalty. Files under it are never retrieved and therefore never inlined into a prompt that goes to your model backend. It is the right place for material you are willing to keep locally but not willing to send anywhere - the folder is configurable with brain.private_folder, including turning the exclusion off entirely.

​
Choosing how much travels

A few practical levers, in rough order of how much they buy you:
  • Keep sensitive material in brain/work/. A hard exclusion is easier to reason about than a careful workflow.
  • Prefer read tools and dry runs while iterating. --dry-run resolves real inputs but executes nothing outward, so you can inspect the prompt before anything is sent.
  • Use the local retrieval backend. retrieval.backend = local is keyword search inside px0, with no model download and no embedding calls. The qmd backend runs its models locally too, so neither backend sends your library anywhere.
  • Scope the Composio key. It needs auth_configs write access to prepare authorizations, but you decide which apps you ever consent to.
  • Skip the update check with update.check = false if you want px0 to make no unprompted network request at all.
  • Set connectors.ca_bundle on an inspected network. It applies to every outbound request px0 makes, so you get working TLS verification rather than the temptation to disable it.

​
Moving or deleting your data

There is no export request to file and nothing to delete on a server, because there is no server.
The export is deliberately safe to hand to someone else or drop into a backup: the Composio key is blanked in the exported config.toml and purged from the exported version history, and .state/credentials.toml is not copied at all. Uninstalling via the install script never deletes your store for you, but px0 uninstall does. See The store.