Screenpipe records everything by default, filters are the real configuration

The pipeline ends in local storage before anything reaches a model

Screenpipe draws its own architecture as one line: screen and audio, into local storage, and from there into a model. Nothing in that line ships your capture to a server first. Capture history stays on the device by default, and cloud AI, sync, integrations and managed team storage are described as separate data paths with their own section in the privacy notes.

The offline claim is narrow, and the exact wording matters. Local capture and search work offline after setup. Cloud AI, sync and connected services require network access. Pull the network cable after setup and the recorder keeps running and local search keeps answering, while anything that depends on a model served elsewhere stops.

What the capture actually covers is longer than the diagram suggests: the full accessibility tree, OCR as a fallback, transcription, speakers, keyboard inputs and app switches. Read together, those are not the contents of a screen recording. The accessibility tree is the primary representation, pixels are the backup, and two of the six channels are not visual at all.

Two npx commands do two different jobs

There are two install paths and they are not equivalent. A desktop app covers macOS, Windows and Linux, and the project attaches one condition to it: available features depend on your plan. No plan caveat is attached to the CLI path.

For the CLI, recording and wiring are separate steps. Recording comes first:

npx screenpipe record

Then setup, or an explicit MCP registration with Claude:

npx screenpipe setup
# or
claude mcp add screenpipe -- npx -y screenpipe-mcp@latest

Those last two lines are not equivalent in practice. The setup command detects agents on the machine and configures them. The claude mcp add form registers one server with one tool and pins it to @latest, which means the build your agent talks to can change under you without you running anything.

Once it is running, the documented way to use it is a sentence rather than a command: `what did i see in the last 5 mins?`, `summarize today conversations`, or `create a pipe that updates linear every time i work on task X`.

setup writes into every agent it detects, not every agent you name

The setup command does more than start a service. The project describes it as installing the screenpipe skills and MCP configuration into every supported agent detected on your computer. Detected, not chosen, is the operative word, and the set of agents it touches depends on what it finds on that machine.

What it writes points at a single file, crates/screenpipe-core/assets/skills/screenpipe-cli/SKILL.md, and any coding agent is asked to read that skill before operating screenpipe. The skill's stated coverage doubles as an index of the surface area: the recorder-first service default, explicit API-only server mode, human and JSON status, local search, safe read-only SQLite access, pipes, and connections.

That list also describes the shape of the data. Pipes are a first-class concept rather than an export, connections are something you configure, and the capture database is reachable over SQLite with read-only access as the documented door. If your plan is to query history from your own code instead of from an agent, that read-only path is the entry point the project names.

The accessibility tree comes first and OCR is the fallback

Capture prefers structure to pixels, and the order in the specs is the whole design decision: full accessibility tree first, OCR as a fallback. Where an application exposes its text through the accessibility layer, the recorder gets real strings. Where it does not, OCR takes over, and the quality of that second path is a different question from the first and is not quantified anywhere in the project.

Alongside the visual channel the recorder takes transcription and identifies speakers, and it also logs keyboard inputs and app switches. Those last two are not screen content at all. App switches are what let a later question be scoped to a stretch of work instead of to a window title. Keyboard inputs are the entry on that list that deserves the most thought before you switch anything on, because it is a capture channel with no counterpart in an ordinary screen recorder and it exists whether or not the rest of the machine is filtered.

Encryption at rest is a switch you have to find, and storage has no default

The filter list is short and specific: window, app, chrome extensions, passwords, and a proprietary AI PII model. Each entry removes a class of content before it reaches storage. Password filtering is the one that decides whether a history is something you can hand to an agent at all.

Encryption at rest is listed as optional, and no default is stated either way. On a machine whose disk is not already encrypted, that single choice is the difference between a plaintext archive of your workday and a protected one.

The resource figures come as ranges with the variables named rather than as guarantees. CPU is approximately 5 to 20 percent, varying with hardware, capture settings, transcription and AI workloads. RAM is approximately 0.5 to 3 GB for capture, with local models and further workloads using more. Storage gets no number at all, because it varies with activity, displays, audio, capture settings and retention. The project tells you to measure a representative day on your device before sizing it, which is honest advice and an admission that there is no figure worth copying from someone else's setup.

Recorder-first and API-only are two deployments, and only one records

The CLI skill covers two shapes of service, and picking the wrong one costs you the feature that made you install it. The recorder-first service default owns capture and serves from what it captured. The explicit API-only server mode serves the API without owning the recording.

API-only is the right shape for a machine you are not sitting in front of, a build agent, a remote session, anything with no desktop to record. It is also what you land on by accident when you start the server without the recorder, and the symptom shows up late as an agent that answers from an empty history rather than as an error at startup.

Status is reported in two shapes, human and JSON, which tells you the project expects both a person and a script to check on the service. Pipes and connections sit alongside them as the two extension points: pipes move recorded events somewhere, connections point at the agents and services those pipes reach.

The Cargo manifest points at LICENSE.md and declares no licence field

The project does not present itself as open source. It calls itself source-available, and the build metadata agrees in a quiet way: the Cargo workspace sets a license-file entry pointing at LICENSE.md and carries no license field at all. The wording is the point of the distinction. Inspect, modify and audit are what the project offers. Distribution, relicensing and reuse inside a product are questions that grant does not answer.

The team path runs through the same licence question. Reviewed outputs can be shared, or managed storage can be configured with agreed access rules, and both sit in a section of their own, separate from the local-first default that an individual install gets. Nothing in the project documentation describes that managed path as something you run yourself, and the boundary between the two is drawn at the pricing page rather than in the code.

For an evaluation, open LICENSE.md before the feature list. What you are allowed to do with six months of captured screen and keyboard history depends entirely on what is in that file.

App, MCP server and workspace carry three unrelated version numbers

Three version lines move independently, and telling them apart matters the moment you read release notes or pin a dependency. App releases are tagged on their own line, v2.7.84 on 2026-10-01 and v2.7.79 on 2026-09-29. The MCP server has a separate line at v0.20.2 from 2026-09-27. The Cargo workspace itself sits at version 0.4.52, and edition 2021 with resolver 2. A fix in the app does not imply a change to the MCP server, and neither number appears in the workspace version.

The workspace also leaves four paths out of the root build: apps/screenpipe-app-tauri/src-tauri, crates/screenpipe-rfdetr-mlx, packages/sdk and .github/ci/ort-smoke, with members set to crates/*. So a cargo command at the root does not build the Tauri shell or the SDK, which is where most of what a user touches actually lives.

One dependency is a git dependency pinned by commit hash, hf-hub taken from a fork at rev 437dcf4049233f4a0e0cfc4e1c1dbf5ed2c57760. That pin is what makes a build reproducible, and it is also a maintenance relationship living outside this repository. The same manifest opens by telling any AI agent to add its header to every source file it creates or edits, even outside the screenpipe repo.

Editorial conclusion

Adopt Screenpipe when you want a coding agent to know what you actually worked on, and you are willing to read the filter list before the first day of recording, because keyboard inputs and audio are part of the default capture set. Do not put it on a machine you cannot supervise, and do not assume the database is encrypted. Before anything else, open LICENSE.md to see what source-available permits you to do with the capture, then measure one representative day on your own device to size the storage.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes