zenshin is an Electron anime list manager with a Puppeteer scraping core

A list manager first, a player second

zenshin describes itself as a poorly written web and electron based anime list manager with media streaming capabilities. The order of that sentence matters, and it is the opposite of what you would expect from the name.

The library side is the durable part. It tracks what you are watching, and the interface is a React application with TanStack React Query for data fetching, Radix UI and Radix Icons for components, TailwindCSS with the animated and line-clamp plugins for styling, React Lenis for scroll behaviour, and Sonner for toasts. There is a date-fns dependency for dates, an infinite scroll component for lists, and axios for requests.

The streaming side is where the fragility sits, and the repository is unusually candid about it. The very first callout in the README is an important notice saying that, since tosho is shutting down, the author has switched to the new tosho-xyz alternative. The branch named tosho-update will use the newer alternative, and the main branch will still use the older URL until the newer API is stable.

That is a project telling you, in the first paragraph, that its data source is being replaced and that the two halves live on different branches. It also means the code in main and the code in tosho-update are not interchangeable, and which one you want depends on which API you intend to talk to.

The project is JavaScript, GPL-3.0 licensed, with v3.0.0 tagged on 2026-05-24, which is also the date of the last push.

How the streaming path is actually built

The topic tags and the dependency list together describe the architecture more precisely than the README prose does.

WebTorrent is in the stack, and it is the reason for the presence of hls.js as a separate concern. WebTorrent gives you peer-to-peer streaming over the browser, and hls.js handles HLS playback, so the project supports both a torrent transport and a conventional HLS one. Puppeteer is the other heavy dependency, and it is there because the data source is scraped rather than queried through a documented API.

The player is Video.js and Plyr, which suggests the custom controls are built on those two rather than on the browser's native video element, with Plyr providing a lighter wrapper for simpler cases.

On the server side there is ExpressJS, and there is a specific integration worth noting. The README documents VLC Media Player support in the web version, where you define the path to vlc.exe in the file BACKEND/server.js:

  const vlcPath = '"C:\\Program Files (x86)\\VideoLAN\\VLC\\vlc.exe"'; // Adjust this path as needed

The hardcoded Windows path with the comment to adjust it is a small window into how the project is put together: a Node backend that knows the file system of the machine it runs on, with configuration done by editing source.

The rest of the stack list is worth reading as a description of what the app does: axios for requests, expressjs for the backend, and the hls and hlsjs topics alongside webscraping, which together separate the transport layer from the acquisition layer.

Building the Electron app is a five step npm routine

The build instructions are concrete and platform specific, which is the most useful part of the documentation for anyone who wants to run this themselves.

The commands for building on Windows, Linux and macOS are given as `npm run build:win`, `npm run build:linux` and `npm run build:mac` respectively, and the macOS one is marked as untested in the documentation.

The full sequence is six steps. Change into the `Electron\zenshin-electron`. Run `npm i` or `npm install`. Run `npm run build:win`. Check the `dist` folder at `Electron\zenshin-electron\dist`, where `zenshin-electron-x.x.x-setup.exe` is the setup and the folder `win-unpacked` contains the pre-installed files. The `Zenshin.exe` inside `dist\win-unpacked` can be used directly if you want to avoid installing the setup. And the same process applies to the other operating systems with their respective build commands, with a linked video showing the build on Ubuntu.

The repository layout matches that split. There is an `Electron/` directory holding the desktop app, an `Archive/` directory at the root that keeps retired work rather than deleting it, and a `disclaimer.md` alongside the README and LICENSE.

One thing to know before you start: the web version of the app is no longer being worked on. The documentation marks the web build instructions as outdated and says to use the Electron app instead.

Subtitles are the known missing feature

The most useful limitation in the documentation concerns subtitles, and it is stated with the reason attached.

The note says the video player inside the browser and the app currently does not support subtitle rendering, because extracting embedded subtitles from an mkv file is quite tricky, and that the author considers it out of their league.

The workaround given is to open the file in VLC or MPV, using the `Open VLC` or `Open in External Player` button when playing an episode.

That is a real limitation for a significant slice of anime watching, since subtitle and sign tracks are the point for a lot of the content. The pragmatic answer is that the app handles the library, the list and the episode selection, and the actual playback falls back to an external player for the cases the built-in one cannot serve.

There is a second note about a different kind of failure. If you cannot access pahe even after refreshing cookies, the suggestion is to try using Cloudflare DNS, with a link to the Cloudflare WARP download page. That is a workaround for network-level blocking of a host the app depends on, and it tells you the app's resilience to a blocked host is limited.

The subtitle limitation and the access issue are different in kind. The first is a known feature gap with a stated cause. The second is the structural fragility of depending on hosts you do not control.

Contributions are welcome as forks, not as pull requests

The contributing section is short and sets an unusual boundary.

Forks are welcomed, but contributions directly to the project and branch are not encouraged as of now. Issues are still open for feature requests, bug reports and any other inquiries.

So the project's model is one maintainer with a clear upstream and a community that is expected to work in its own forks. That is a legitimate choice for a project built on scraped data with a moving upstream, because accepting outside patches to scraping logic would create a maintenance burden the maintainer plainly does not want to carry.

It also means the code in the main branch is effectively a snapshot. If the tosho source shuts down as the notice says, the fix lives in the tosho-update branch or in a fork, and the main branch will not follow automatically.

The repository also carries a disclaimer file at the root, and the README links to it under a Disclaimer heading. The contents of that file are not in the repository overview, so anyone considering using the app should read it directly rather than assume what it says.

The release tags tell a similar story. v3.0.0 came on 2026-05-24, v2.7.1 on 2026-04-24 and v2.7.0 on 2026-03-09, so the project is on a 3.x line with regular releases through spring 2026, and the last push matches the v3.0.0 tag date.

Where this sits against the official streaming clients

The comparison that matters is with the official clients from the anime services, and the difference is not in the interface.

An official client gets a documented API, a stable catalogue, working subtitles and a supported playback path, because the company behind it controls the data and the encoding. zenshin gets none of that and reconstructs what it can: it scrapes catalogue information, resolves streams through a third-party host, and plays them with WebTorrent or HLS in a custom player.

What the project does better in some respects is ownership of the experience. The library is local, the data is yours, the interface is built with the component set you would choose, and the Electron app means it does not depend on a browser tab staying open. For someone who wants a tracker with a custom interface and does not mind maintaining it, that is a reasonable trade.

The cost is that every dependency outside the repository can change without notice, and the project has already been hit by that. The upstream shutting down is not a hypothetical risk that the README worries about; it is the first line of the documentation, and the fix is a branch that exists because of it.

There is also a legal dimension that the disclaimer file addresses and that the reader should look at directly. Scraping and redistributing a service's catalogue and streams is a different act from building a client for it, and the honest position is that the tool's usability depends on sources that may not permit this use.

Editorial conclusion

Adopt zenshin if you want a desktop anime tracker with library management and a custom player, and you are willing to maintain the scraper yourself, since the upstream source is changing and the project keeps the old and new APIs on separate branches. Skip it if you need a service that will keep working without your attention, or if you want subtitle support in the built-in player, which the project lists as unsupported. Verify first which branch you are on, because main still points at the old URL while the tosho-update branch targets the newer alternative, and check the disclaimer file in the repository before you rely on it for anything.

Frequently asked questions

Official sources

1. hitarth-gg/zenshin on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases