Puter
Puter is 1Context’s Mac remembering app: a desktop recorder meant to capture screen, audio, UI events, terminal activity, and related observations without inheriting the full product shape of Screenpipe. It exists because 1Context needs desktop evidence that can become usable memory, not just a pile of files or a borrowed app shell. As of April 24, 2026, Puter is mid-transition from a stripped Screenpipe fork into a native Mac menu-bar recorder with its own engine, observation model, and privacy boundaries.
Origin
Puter appeared on March 30, 2026, when the Screenpipe fork was split into its own app identity, bundle name, release script, credentials path, smoke checks, and standalone repo. The first named release was v2.2.226, published after the old app’s menus and popovers had become a distraction from the simpler product Paul wanted: a Mac tool that helps you remember.
The pressure came from two directions. Guardian and later 1Context needed dependable personal memory evidence, while Screenpipe supplied useful recorder internals but too much unrelated product baggage: chat, search, rewind, sync, calendar, login, tutorials, and inherited desktop assumptions. Puter kept the recording function and began removing the rest.
Role in 1Context
Within 1Context, Puter is part of the capture layer. It records desktop evidence that can later be summarized, indexed, or related to wiki pages, session history, and agent work. It sits beside Phonecapture, which records phone HDMI output through a Jelly Star, and Littleguy, which investigates wearable camera hardware.
Puter’s data is not meant to become polished memory by itself. Its job is to produce local observations: frames, OCR or accessibility elements, audio chunks, UI events, terminal sessions, clipboard-related events, and media references. Downstream systems can turn those observations into summaries or wiki-visible claims only after preserving enough provenance to argue about what happened.
The current direction aligns with the broader 1Context storage split: local observations and capture state live on the Mac, with embedded LanceDB/Lance favored for local tables and indexes, while hosted truth belongs in Postgres. Terminal logs are treated as message observations with conversation_id, not as a one-off terminal category.
History
March 31 forced Puter to behave like a Mac app rather than only a renamed fork. The menu-bar icon had been stranded at x: 3734 after an external display disappeared. Display-layout changes began recreating and re-anchoring the status item; wake recovery stopped reopening hidden windows; launch and shortcut paths moved away from the old fullscreen Rewind overlay into a small home window. Release 2.2.244 kept the Puter app and bundle name, changed the GitHub description to Puter helps you remember., and produced Puter_2.2.244_aarch64.dmg, though Gatekeeper still rejected that artifact because it was development-signed and not notarized.
On April 3, Puter hit the limit of the Tauri wrapper. The menu-bar item could exist in Accessibility inspection and still not be trustworthy on screen. After attempts to repair tray behavior, wake handling, onboarding paths, and failed-state icons, the repo was rolled back to b1fe28b9b while preserving camera-capture work. A scratch Swift menu-bar app proved the native approach, and Puter gained apps/puter-native-macos, EngineController.swift, and a milestone doc for the native wrapper. The user-facing language changed to Start remembering, Stop remembering, Remembering normally, and Remembering with limits.
That same day, puter-engine became a product-specific binary under crates/screenpipe-engine/src/bin/puter-engine.rs. A later installed-app failure traced to boolean-style Clap flags such as --use-all-monitors=false; adding inverse flags like --single-monitor and --no-system-default-audio let the native wrapper launch the engine correctly. Server 3030 then reported screen and audio recording, and a transcription loop proved VAD and database rows after correcting the expected column from text to transcription.
April 10 shifted Puter’s truth model for permissions. Direct CLI permission probes were demoted because they could report Accessibility trust while the launched app still lacked what it needed. /health moved toward reporting the runtime state of the installed app: permission freshness, configured settings, resource use, storage use, stream activity, and workload. Native Swift input monitoring replaced inherited helper assumptions, and fresh ui_events proved Input Monitoring from the installed app path.
Current State
As of April 24, Puter is being pulled out of Screenpipe inheritance into a native Mac recorder with its own product contract. Its model rejects decorative structure: UI events are bound to frames; tags are observations; terminal logs are message observations; clipboard capture has only off and clipboard as content modes, while clipboard activity remains ordinary event history.
A newer puter2 direction also exists: a single Rust workspace with puter2-db and puter2-engine. Classic Puter has added PTY-backed terminal-session capture through its own session manager, routes, and database migration rather than relying on external terminal tools such as tlog.
Relationship to Other Subjects
Puter is the successor to the useful recorder parts of Screenpipe, not a continuation of Screenpipe as a full product. It is one of the evidence feeds for 1Context, alongside Phonecapture and Littleguy. Its health, schema, and capture policy also connect to sessions.db and wiki-engine, because desktop evidence only becomes durable project knowledge when it can be checked, summarized, and linked without losing provenance.
Open Questions
Puter’s final observation schema remains unsettled. The direction is clear, but the implementation still has to make unified observations operational, migrate legacy Screenpipe-shaped data where needed, and keep health checks tied to the launched app’s real permissions. Retention, privacy defaults, and the boundary between private desktop evidence and wiki-visible knowledge are also still open inside 1Context.