Papr: one local database behind a Tauri reader and an agent-facing RSS CLI
A fast, native RSS reader — plus an agent-facing CLI so your AI agent can read, search and triage your feeds from the shell.
At a glance
- What is it?
- Papr ships a desktop RSS reader and a shell CLI that share the papr-core crate, so an autonomous agent can triage the same feeds you read. The CLI's TOON output and its FreshRSS and Miniflux sync are the parts worth judging before you adopt it.
- Who is it for?
- Adopt Papr if you already run an agent such as Claude Code, Codex or OpenCode in a terminal and want feed triage to happen there, or if you want a local-first reader with no account and you accept that FreshRSS or Miniflux is the only path to a second device. Skip it if you need a hosted web reader you can open in any browser, or if your feeds are the shared inbox of a team rather than one person's reading list.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Papr picks: an agent that cannot see your feeds
An agent working in a shell can read files, run tests and edit code, but it has no view of the articles you have queued. The usual workaround is to paste links or dump a feed export into the conversation, which loses read state and does not scale past a handful of items. Papr's answer is a CLI, papr, that exposes the same feed store the desktop app uses. The README describes it as a command-line companion built for autonomous agents to drive over the shell, with four verb groups: read (feeds, list, read, search), triage (mark, extract, refresh), manage (subscriptions, folders, tags, rules, highlights, OPML) and sync (FreshRSS, Miniflux). The intended user is someone who already runs Claude Code, Codex or OpenCode in a terminal and wants feed handling to be one more tool the agent can call, not a browser tab they have to babysit. A second audience exists: people who want a native, offline-first reader with no account and no cloud, and who treat the agent CLI as a bonus rather than the reason to install.
One database, two front-ends, one shared crate
The architectural claim in the README is narrow and testable: Papr is two front-ends over one local database, and both read it through the shared papr-core crate, so the app and the CLI can never drift apart. That is the design decision that matters. A separate CLI that reimplemented feed parsing would eventually disagree with the GUI about what counts as unread, how tags apply, or what a rule matched. Sharing the core crate removes that class of bug by construction. The stack is Rust with a Tauri desktop shell and a React front-end, which is consistent with the topics list and with the packaging targets (a .dmg, an .msi, an .AppImage and a .deb). The desktop side covers the expected reader surface: feeds and folders with OPML import and export, smart views for All, Unread, Starred and Read Later with live counts, color-coded tags, and rules that tag new articles automatically. Full-text fetching cleans the complete article when a feed ships only a summary. Everything stays on the machine. There is no account and no cloud component, which also means there is no server-side index to search and no vendor holding your subscription list.
Getting it installed on macOS, Windows and Linux
The README gives per-platform install paths. On macOS the desktop app is `brew install --cask l0ng-ai/papr/papr`, or a .dmg from the latest release; the README states that macOS builds are Developer ID signed and notarized, which matters because an unsigned Tauri app is a Gatekeeper fight. Windows uses a .msi installer, Linux an .AppImage or .deb. The CLI is distributed separately: `brew install l0ng-ai/papr/papr-cli` on macOS and Linux, a `papr-x86_64-pc-windows-msvc.zip` on Windows where you unzip and put papr.exe on your PATH, or a prebuilt `papr-<target>.tar.gz` from the release page. Building from source is `cargo build --release -p papr-cli`. The agent integration has two levels. The bundled skill at skills/papr-rss/SKILL.md loads on demand when an agent recognizes a feed-related task, and installs with `npx skills add https://github.com/l0ng-ai/papr/tree/main/skills/papr-rss`. If you want the agent aware of your feeds in every conversation instead, `papr setup` wires up an ambient SessionStart hook for Claude Code, Codex and OpenCode. The README points to docs/cli.md for the full command reference, which is where I would look before trusting any of the above in a scripted workflow.
TOON output and the bare papr dashboard
Running papr with no arguments prints an unread dashboard plus what the README calls the next useful commands, so an agent can orient without being told anything. The example in the README shows a summary line (unread, starred, later, feed counts) followed by a tabular block of articles with id, feed, title, flags and date, then a short help list suggesting `papr read <id>` for full text. Output is TOON, which the README describes as roughly 40 percent fewer tokens than JSON, with definitive counts and structured exit codes. Two details are worth separating. The token saving is a claim about the format, not a benchmark I can confirm; take it as a design goal. The structured exit codes are the more consequential part for agent use, because they let a calling process branch on failure without parsing prose. The dashboard's flags field carries state like unread and starred inline, which is what lets an agent decide what to triage without a second call. If your agent already handles JSON tool output well, the gain here is smaller than the README implies; if you are paying per token on long feed lists, the format is the reason to care.
What Papr does not do, and where it is the wrong tool
The README lists FreshRSS and Miniflux as the sync targets and nothing else, so multi-device read state depends on you running one of those two servers. There is no hosted Papr service to fall back on, and no browser client. If you read feeds on a phone, a tablet and a work laptop and you do not want to operate FreshRSS or Miniflux, this is the wrong reader for you, regardless of how good the CLI is. The AI features (summaries, ask-the-article Q&A, digests) require you to bring your own API key, so there is no bundled model and no flat cost. The agent CLI also assumes a Unix-like shell workflow; the Windows path is a manually placed papr.exe, which is workable but clearly the less trodden route. Finally, the release cadence visible in the supplied material is tight: v0.13.1, v0.14.0 and v0.15.0 all landed on 2026-07-11, and the last push to the default branch was 2026-09-03. Rapid minor releases at a 0.x version number mean the CLI surface can move; pin a version if an agent prompt depends on exact command names or exit codes.
How it differs from Miniflux and FreshRSS as a client
Miniflux and FreshRSS are server applications: you deploy them, they hold the database, and clients connect over an API. Papr inverts that. The database is local, the reader is a native desktop app, and the server relationship is optional and outbound, used only to keep read state in step. That difference decides your failure modes. A self-hosted Miniflux instance is reachable from any browser and any device, but it is a service you patch and back up. Papr is reachable from one machine, needs no server, and its data lives in a local file you can copy; the price is that the second device problem is yours to solve through FreshRSS or Miniflux sync. The agent angle sharpens the split further. A Miniflux API can be called by a script, but you would be writing the triage logic yourself against HTTP endpoints. Papr ships the triage vocabulary as subcommands and a skill file, which is a real difference in effort even if the underlying capability overlaps. If you already run Miniflux, Papr is a client for it rather than a replacement.
Licence, maintenance and upgrade cost
Papr is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is the permissive end of the spectrum and it removes the licensing question for most teams, though I am not giving legal advice and you should read the LICENSE file in the repository before shipping a fork. The maintenance picture from the supplied material is active: releases through v0.15.0 in July 2026 and a push to main in September 2026, with no archive flag. The upgrade cost is concentrated in two places. First, the 0.x version line means CLI output and exit codes can change between minors, so an agent prompt or a wrapper script pinned to a specific flag should be tested against each release. Second, the desktop app and CLI are packaged separately (papr-cli versus the cask or installer), so upgrading one without the other can leave you on mismatched versions of a shared database. The README's claim that both front-ends read through papr-core limits schema drift, but it does not promise that an older binary handles a newer database.
Editorial conclusion
Adopt Papr if you already run an agent such as Claude Code, Codex or OpenCode in a terminal and want feed triage to happen there, or if you want a local-first reader with no account and you accept that FreshRSS or Miniflux is the only path to a second device. Skip it if you need a hosted web reader you can open in any browser, or if your feeds are the shared inbox of a team rather than one person's reading list. Before committing, check the release notes for v0.15.0 and later, confirm the papr-rss skill in skills/papr-rss/SKILL.md covers the commands you need, and verify that your sync server is actually FreshRSS or Miniflux, because nothing else is listed.
Community notes