---
title: "Screenpipe"
slug: screenpipe
section: reference
access: public
summary: "Screenpipe was the inherited desktop capture product that gave 1Context its first working Mac recording corpus. Inside 1Context, it mattered less as a finished application than as a source of recorder internals: screen frames, audio, OCR, transcription, UI events, and a real `db.…"
status: published
asset_base: /assets
home_href: /
toc_enabled: true
talk_enabled: false
agent_view_enabled: true
copy_buttons_enabled: true
footer_enabled: true
last_updated: 2026-04-29
categories: [Tools]
subject-type: tool
last-reinforced: 2026-04-29
fading-since: null
archived: false
---

## Screenpipe

Screenpipe was the inherited desktop capture product that gave [1Context](/1context) its first working Mac recording corpus. Inside 1Context, it mattered less as a finished application than as a source of recorder internals: screen frames, audio, OCR, transcription, UI events, and a real `db.sqlite` large enough to break naive import assumptions. As a full product it is retired as of April 24, 2026, with its useful recorder lineage continuing through [Puter](/puter).

**Origin**

Screenpipe entered the project before 1Context had its own name, when [Guardian](/guardian) needed real user-source imports instead of toy files. By March 25, 2026, its data root had moved to `~/dev/screenpipe-data`, Pro gates had been removed from the fork, and macOS identity plus launch-agent behavior were being hardened. The practical pressure was evidence: desktop memory had to produce artifacts the rest of the system could ingest, inspect, and verify.

The initial value was not conceptual novelty. Screenpipe already contained the rough machinery of a lifelogging recorder. It could produce many files per day, including a large local SQLite database, and it exposed the difference between a demo capture path and a source that stresses transport, import state, and timeline generation.

**Role in 1Context**

Screenpipe served as an upstream evidence source. GuardianDesktop and guardianbackend used Screenpipe folders as import benchmarks, including smoke paths that produced `96` files and `7` timeline buckets, then `455` source files and `27` timeline buckets from `Screenpipe Folder Prod Smoke`. Its `db.sqlite`, later observed around `1.96 GB`, forced Guardian to add direct-to-storage upload sessions for oversized files rather than treating every source as ordinary public shard traffic.

Screenpipe also shaped 1Context’s vocabulary around capture. By March 30, the project had concluded that “Screenpipe” was not one coherent user experience. It was a corpus from which experiences could be inferred. That distinction fed memory-editor, lifelog-compression, and later [Puter](/puter): raw capture, sparse visual bundles, audio derivatives, captions, and timeline views should not be collapsed into a single app metaphor.

**History**

On March 25, Screenpipe crossed from reference app to modified fork. The fork removed paid-product gates, made the data root local and explicit, and became part of the closed-loop validation habit that later appeared in coding-agent-config. Screenpipe imports then became a scale test for Guardian’s cloud path.

On March 28, Screenpipe folders were among the sources that made per-file upload look too expensive. Guardian moved toward shard upload, backend expansion, queued processing, and VM materialization. That same work exposed cleanup requirements for temporary tarball transport parents.

On March 29, the fork was renamed by subtraction into GuardianScreenPipe. Commit `4069a8325` on `stripped-down-screenpipe` recorded the major cut: `258 files changed` and `78,171` deletions. The old chat, search, rewind, login, sync, deep-link, and hosted product features were removed. The remaining obligation was narrower and more relevant: keep frame, audio, OCR, transcription, and UI capture alive.

On March 30, the renamed lineage became [Puter](/puter). Puter split from the Screenpipe fork, took its own bundle identity, and released as `v2.2.226`. The project also used Screenpipe material to populate an early memory-editor prototype with frames, audio, OCR captions, and transcript VTTs.

On March 31 and April 3, Puter’s distance from Screenpipe increased. The app’s tray behavior, macOS menu-bar identity, and native wrapper became more important than preserving the old Tauri product shell. Camera recording was investigated against local Puter code and upstream Screenpipe repositories; no first-class camera capture system was found. On April 3, Puter rolled back to release `2.2.244` while preserving camera work, then added `apps/puter-native-macos` and a product-specific `puter-engine` binary under `crates/screenpipe-engine/src/bin/puter-engine.rs`.

**Current State**

Screenpipe as a full product is retired within 1Context as of April 24, 2026. The reason was product mismatch. Its recorder internals were valuable, but the surrounding application carried too much unrelated baggage: chat, search, rewind, sync, calendar, deep links, login shell, and tutorial paths. 1Context kept the remembering function and discarded the inherited product frame.

The surviving line is [Puter](/puter). Puter is being pulled out of Screenpipe inheritance into a native Mac recorder with its own contract. Its newer decisions reject decorative structure: UI events bind to frames, terminal logs become message observations with `conversation_id`, tags are observations, local storage uses embedded LanceDB, and hosted truth is expected to live in Postgres.

**Relationships**

Screenpipe is closest to [Puter](/puter), which inherits and narrows its recorder role. It is also connected to [Guardian](/guardian) and guardianbackend, because Screenpipe folders and `db.sqlite` forced import changes around shards, direct upload, oversized files, and timeline buckets. It relates to memory-editor and lifelog-compression as a source corpus for later timeline and bundle thinking.

Screenpipe is a retired sibling of other borrowed systems such as [Wiki.js](https://js.wiki/) and [BookStack](/bookstack). In each case, 1Context learned from an existing tool, then rejected the parts that tried to define the product boundary for it.