Skip to content
Pibmo

Pibmo Recall

A faithful, append-only archive of AI coding sessions -- Claude Code, Gemini, Codex -- on machine-local storage, so transcripts survive the tools' rotation windows. Sync runs hourly from a git checkout; nothing is overwritten, nothing is deleted, and no step calls an LLM.

Install

runs from the checkout

Clone the repo

git clone https://github.com/attilabalogh/pibmo-recall.git ~/code/pibmo-recall

Then run the installer

cd ~/code/pibmo-recall && bash install.sh

The installer proposes the platform-default local root and refuses cloud-synced paths for it -- a cloud folder belongs as the consolidated root, not the local one. It registers the machine, seeds shared config, and writes the native scheduler unit; it never edits your crontab and writes nothing outside the dataset root and the unit file. Updating is git pull: the unit points at the checkout, so the next tick runs the new code. There is no deployed copy and no self-updater.

Is this machine actually archiving?

every failure prints its fix
atlas 
$ python3 ~/code/pibmo-recall/scripts/sync/doctor.py \
    --root "$HOME/Library/Application Support/pibmo/recall" \
    --consolidate ~/Dropbox/Datasets/pibmo
Pibmo Recall doctor -- machine 'atlas', root /Users/dev/Library/Application Support/pibmo/recall
  OK    root         /Users/dev/Library/Application Support/pibmo/recall/machines.json readable (2 machine(s) registered)
  OK    identity     6f2a91c4...
  OK    registered   'atlas'
  OK    writable     canary ok under atlas/logs/
  OK    unit         1 unit file(s) current
  OK    unit-cmd     embedded interpreter and script exist
  OK    heartbeat    last completed sync 2026-07-22T09:00:11.482913+00:00 (0.4h ago)
  OK    log          /Users/dev/Library/Application Support/pibmo/recall/atlas/logs/cron.log (modified 0.4h ago)
  OK    consolidated this machine's replicated heartbeat 2026-07-22T09:00:14.107255+00:00 (0.0h behind local)
  WARN  fleet        harbor: heartbeat 27.3h old
        fix: that machine (or its transport) has gone dark -- run the doctor there
Summary: 9 ok, 1 warn, 0 fail

The data path

copy, then consolidate
Session data flowing from the AI tools' home directories into an append-only local dataset root, then to a consolidated root The home directories of Claude Code, Gemini, and Codex are read by an hourly scheduler unit, which copies new session data into a local dataset root on machine-local disk, where the archive is append-only and provenance is recorded in SQLite. A separate transport step folds this machine's subtree into the shared consolidated root, which joins machines and may itself be cloud-synced. tool homes ~/.claude ~/.gemini ~/.codex local root machine-local disk append-only pibmo.db provenance consolidated root joins machines may be cloud-synced sync hourly unit consolidate transport step what moves is a faithful copy appends extend -- rewrites fork -- nothing deleted no step calls an LLM -- credentials never enter the archive
Archiving is a copy. The hourly unit mirrors each tool's home into the machine-local root; consolidation folds per-machine subtrees into one shared root as a separate transport step. By design, replication beyond that is delegated to tools built for it.

The moving parts

scripts, not a daemon
install.sh
Propose a local root, register the machine in machines.json, seed shared config, and write the scheduler unit.
sync-transcripts.py
Archive new session data from the tool homes. Safe any time; concurrent runs exit immediately via a lock.
doctor.py
Check registration, unit, heartbeat, and replication lag. Every failure prints its exact remediation.
scheduler.py
Render, write, or verify the native scheduler unit -- LaunchAgent on macOS, systemd user timer on Linux.
process_root.py
Project the raw archive into merged per-project Markdown under denylist profiles.

Deployment shapes

both first-class

The local root must be a plain local path -- the installer refuses cloud-synced and remote paths for it rather than archiving onto storage that a mount, permission fence, or network can deny. Nothing beyond the first shape is ever required; the second is opt-in for operators with more than one machine.

single-machine

One local dataset root at the platform-default path. Install, accept the proposed root, activate the unit -- done. No cloud storage, no consolidation, no extra tooling; this is the whole product on one machine.

roots
one, machine-local
scheduler
LaunchAgent / systemd timer
consolidation
never comes up

multi-machine

Each machine archives to its own local root, and every sync additionally pushes that machine's subtree into one shared consolidated root. Replicating that root to cloud storage is delegated to a tool built for it.

roots
one local per machine + one shared
transport
--consolidate on the unit line
replication
delegated -- rclone or vendor client

Preservation scope

what is and is not guaranteed

Preservation is not replication

Recall provides preservation: the archive is append-only, so a transcript is never overwritten or shrunk. Appends extend it, a divergent rewrite -- compaction, for instance -- is kept as a sibling fork file, and regressions are skipped. Nothing is ever deleted.

It does not provide replication. The local root protects transcripts from the tools' rotation windows, not from the loss of the disk they sit on. Durability beyond one machine comes from the consolidated root and from replication delegated to tools built for it -- Recall deliberately ships no cloud client of its own.

The archive is also faithful, and faithful cuts both ways. Credential files never enter it, but transcript content is not redacted at sync time -- everything your sessions saw is in the root. Filtering happens later, in the deterministic processing layer, under denylist profiles. Treat the dataset root with the sensitivity of the sessions it holds.

Documentation

Getting started Concepts Architecture Troubleshooting