Screenpipe
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.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.
Origin
Screenpipe entered the project before 1Context had its own name, when 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: 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 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 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, which inherits and narrows its recorder role. It is also connected to 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 and BookStack. In each case, 1Context learned from an existing tool, then rejected the parts that tried to define the product boundary for it.