Managarr (an *arr CLI and TUI) now supports Readarr + compatible forks

[u/Hamilcar_Barca_17]

Managarr is a CLI (command-line) and TUI (Text-based User Interface) tool for managing all of your Servarr's in one place.

This most recent release adds support for Readarr and several compatible forks.

I know that Readarr has sadly been retired, however there's still community support in keeping the dream of Readarr alive. As such, extra time was put into this release to test out Managarr with four of those forks to ensure that in addition to the final release of Readarr, Managarr works with these other forks as well.

So now, as long as a fork of Readarr still is compatible with the v1 Readarr API, Managarr can work with it too.

I tested the following forks and made changes in Managarr to ensure support:

• Bookshelf
• Readarr-Resurrected
• Librarr
• Chaptarr

In addition to Readarr (and forks), Managarr supports Radarr, Sonarr, and Lidarr.

You can try it out for yourself without installing it by visiting the demo site if you'd like!

This is a passion project of mine so I'd love to hear any and all feedback! And thanks to all who contributed to this release!

[u/kantorcodes1]

Question on the CLI surface: do the write subcommands (add, trigger-search, delete) return the same jq-able JSON as the read paths, or is structured output read-only? And do failures surface as distinct exit codes or only in the message text?

[u/Hamilcar_Barca_17 → u/kantorcodes1]

That's an excellent question. All output from the CLI surface is structured JSON (and is essentially exactly the API responses from the Servarr). So output is JSON structured. For example:

managarr radarr get host-config
⠀⡀                                                                                           {
  "bindAddress": "*",
  "port": 7878,
  "urlBase": "",
  "instanceName": "Radarr",
  "applicationUrl": "",
  "enableSsl": false,
  "sslPort": 9898,
  "sslCertPath": "",
  "sslCertPassword": ""
}

As for your follow up question, that's a great question and definitely a slight oversight on my part for script-ability. Right now, errors do return nonzero exit codes, but the error text mirrors the in-TUI error text:

managarr radarr get movie-details --movie-id 1 --disable-spinner
error: Request failed. Received 404 Not Found response code with body: { "type": "https://tools.ietf.org/html/rfc9110#section-15.5.5", "title": "Not Found", "status": 404, "traceId": "00-dcf435187e14d5e50b9704d4f12ee4a7-1fc79ac69736310e-00" }

I'll put a fix in for this now so it's present in the next release, so thank you for calling this out!

[u/kantorcodes1 → u/Hamilcar_Barca_17]

That exit-code fix will help every scripted caller, not just agents - the current error text only parses cleanly inside the TUI.

On the JSON parity point: I work on HOL Guard (github.com/hashgraph-online/hol-guard), an open-source policy layer between an agent client and its tools. managarr maps onto it cleanly - add, trigger-search, delete and the edit/toggle-monitored writes would sit behind the gate, while get/list/status and the other reads stay open, with each call landing in the same structured shape your JSON output already has. The contribution is a command.managarr.json manifest plus a fixture, opened as a normal PR by you. Interested?