fieldtheory-cli: Field Theory CLI: The Bookmark Sync Tool That Turns X Saves Into Local Memory
A local-first TypeScript CLI that bypasses API friction, builds a durable searchable archive, and hands your bookmarks to both you and your agents as usable context.
- Field Theory CLI is not really a bookmark backup tool, because it turns saved links into a local memory substrate that people and agents can query.
- Its biggest technical move is refusing to depend on official APIs and instead using browser-session access, local storage, and portable search infrastructure.
- SQLite and FTS5 make the archive behave like durable infrastructure, not a fragile cache or export file.
- The project sits in a different category from cloud bookmark managers: it optimizes for sovereignty, scriptability, and agent-ready reuse.
Bookmarks Are Not the Product
The obvious reading of fieldtheory-cli is simple: it syncs X bookmarks to your machine. The better reading is sharper. It treats those bookmarks as a local memory substrate, something a human can search and an agent can reuse.
That shift changes the category. This is not a read-it-later clone, and it is not a nostalgic backup utility. It is a translation layer between platform-bound fragments and durable context.
Sync and locally store all of your X/Twitter bookmarks. Free and open source CLI for Mac.
How It Pulls Data Without Begging an API
The interesting part is not that it fetches data. It is how it gets around the usual dead end of social platform APIs. The repo leans on browser-session access and cookie extraction, which means the tool can sync what you already see in your browser instead of waiting for a vendor to hand you a sanctioned pipe.
That is a tradeoff, not magic. It buys control and removes a lot of API friction, but it also means the project must deal with real operating-system plumbing. That is why the codebase includes dedicated cookie-handling paths for different platforms.
The Local Database Is the Real Product
Once the data is local, the repo starts behaving less like a sync script and more like infrastructure. The core storage layer uses SQLite with FTS5, so search is not an afterthought. It is part of the model.
// The important idea is not the exact SQL shape.
// It's that local data is written atomically and indexed for search.
await saveDb(tmpPath, finalPath);
const results = db.prepare(`
SELECT title, url, snippet(bookmarks_fts)
FROM bookmarks_fts
WHERE bookmarks_fts MATCH ?
ORDER BY bm25(bookmarks_fts)
`);The reliability detail matters. The storage path uses an atomic write pattern, which is the sort of thing you notice only when something goes wrong. Write to a temp file, sync it, rename it, sync the parent directory. That is the mindset of software that expects to be trusted.
From Saved Post to Searchable Knowledge
This is where the repo stops looking like a bookmark utility and starts looking like a knowledge system. Raw saves can be enriched, normalized, exported to markdown, and assembled into a wiki-like library. The output is not just archivable, it is legible to both humans and language models.
That is the core surprise. The project does not merely preserve the link. It reshapes the thing into a format that can be reread, queried, and used as promptable context later.
| Stage | What it produces | Why it matters |
|---|---|---|
| Raw bookmark | A saved X link | Captures the source without losing the original reference |
| Enrichment | Fetched page content and metadata | Adds substance beyond the tweet or title |
| Markdown export | Readable local documents | Makes the archive navigable by people and tools |
| FTS index | Searchable text corpus | Turns memory into retrieval |
| Agent context | Structured payload for an LLM | Makes the archive reusable in workflows |
Why This Beats SaaS Bookmark Managers for This Use Case
Cloud bookmark managers are good at convenience. They are built for sync, tagging, and a polished UI. That is useful, but it is not the same problem.
Field Theory CLI optimizes for control, scriptability, and local agent workflows. It keeps the archive on your machine, works through the command line, and produces outputs that a human and a model can both consume without asking a vendor for permission.
| Dimension | Field Theory CLI | Cloud managers / generic scrapers |
|---|---|---|
| Data model | Local SQLite plus FTS5 | Vendor database or flat export |
| Access | Browser-session based | Often API- or service-dependent |
| Primary interface | CLI and local files | Consumer UI |
| Best use case | Agent-ready personal memory | Convenient saving and reading |
| Ownership | User-controlled | Platform-controlled |
| Workflow fit | Scriptable and composable | Mostly manual |
The Tradeoffs Are the Story Too
The project is impressive because it accepts constraints instead of hiding them. A Mac-focused workflow, session and cookie handling, and a single-maintainer codebase all narrow the audience. They also make the tool more honest about what it is.
It is not pretending to be universal. It is building a narrow, high-trust path from platform content to local memory. That focus is what makes the architecture feel coherent.
What Field Theory Is Really Building
The bigger pattern is easy to miss if you only look at the bookmark sync surface. Personal data becomes more useful when it is locally owned, searchable, and agent-readable. That turns a pile of saved links into a reusable substrate for research, writing, and coding.
In that sense, fieldtheory-cli is less a bookmark tool than a prototype for post-platform memory. It assumes your archive should not just survive export. It should stay alive inside your workflow.