Nuclear Music Player: a Tauri desktop player with a plugin-driven streaming stack

What Nuclear solves, and who it is built for

Most desktop music players assume you already have a library, or they assume you have a subscription. Nuclear takes a third position: the README describes it as a free, open-source music player without ads or tracking, where you search for any song or artist, build playlists, and start listening. The music itself comes from streaming sources that plugins provide, not from files you own and not from an account you pay for.

The audience is narrow and specific. This is for people who want a native desktop client rather than a browser tab, who are willing to install plugins to make search return anything at all, and who care that the client does no tracking. It is equally aimed at developers: the repository is a pnpm monorepo, the plugin SDK is published on npm, and the README states that every functionality has been redesigned to be driven by plugins. If you want a player you can extend rather than merely configure, that design choice is the whole product.

How the plugin system and the MCP server actually fit together

The architecture visible in the repository is a Tauri application: Rust on the native side, React on the interface side, packaged as a monorepo managed with Turborepo. The root package.json routes nearly everything through turbo, with filters for @nuclearplayer/player and @nuclearplayer/ui on the dev script. That split matters when you build from source, because a change to the UI package and a change to the player are separate compilation units.

The interesting layer sits above that. According to the README, plugins can provide streaming sources, metadata, playlists and dashboard content. That means search results, artist biographies, discographies, similar artists and album track listings are not hardcoded against one backend. They are assembled from whatever plugins are installed. A fresh install with no source plugin is a player with nothing to play, which is the trade-off the design accepts in exchange for not being tied to a single provider.

The MCP server is the second extension point. The README says you enable it in Settings, Integrations, after which it listens on http://127.0.0.1:8800/mcp. Any MCP-capable client can then drive the player. The README notes the server is designed to be discoverable, and points to a downloadable skill archive for agents that need more context. Note the binding: 127.0.0.1, not 0.0.0.0. Remote control over the LAN is a separate concern, handled by the dev:remote script, which sets VITE_HOST=0.0.0.0.

Installing Nuclear and getting one track to play

There are two paths. The first is the Releases page, which the README points to for the latest build. Windows ships as an .exe installer or .msi, macOS as a .dmg for Apple Silicon and Intel, and Linux as .AppImage, .deb, .rpm or .flatpak. The repository also carries aur/, flatpak/ and snap/ directories, so those packaging channels exist in-tree, though the README documents only the release artifacts.

The second path is building from source. The README lists the prerequisites plainly: Node.js 22 or newer, pnpm 9 or newer, stable Rust, and the platform-specific Tauri dependencies. The clone and install sequence is:

git clone https://github.com/nukeop/nuclear.git
cd nuclear
pnpm install
pnpm dev

After pnpm dev, the player should launch in development mode. If you want to reach the remote control interface from another device on your network, the README offers a variant that binds Vite to all interfaces:

pnpm dev:remote

The root package.json confirms this by setting VITE_HOST=0.0.0.0 before invoking turbo. For a packaged build rather than a dev run, pnpm build compiles all packages, and pnpm tauri passes through to the Tauri CLI inside the player package.

Once the player is open, the first real task is installing a source plugin from the built-in plugin store, since search and streaming depend on one. After that, wire up an agent if you want one:

claude mcp add nuclear --transport http http://127.0.0.1:8800/mcp

The README gives this exact command for Claude Code, and a near-identical codex mcp add nuclear --url form for Codex CLI. The JSON configuration for OpenCode, Claude Desktop, Cursor and Windsurf uses the same URL under an mcpServers or mcp key.

Where Nuclear stops being the right tool

The plugin model is also the main limitation. Because streaming sources come from plugins, the quality and availability of search results depend on third parties the project does not control. The README does not document a fallback source, a bundled default provider, or what happens to a playlist when the plugin that supplied its tracks is removed. If you need predictable playback of a catalogue you can name in advance, a player with a fixed, licensed backend is a better fit.

Platform coverage is desktop only. The README lists Windows, macOS and Linux and says nothing about iOS or Android, so this is not a phone player. The MCP server binds to localhost, which means an agent on another machine cannot reach it without a tunnel you set up yourself; the README does not describe one.

There is also the question the README never answers: it does not state where the audio legally comes from, nor does it make any claim about the licensing status of a given source plugin. That is a gap a prospective user has to close on their own. The documentation is similarly silent on rollback or downgrade, so if a release breaks a plugin, the README gives no recovery procedure.

Nuclear compared with a library-first player like VLC

The closest mental model is not another streaming client but a local-library player such as VLC. VLC reads files and streams you point it at, and its behaviour is entirely determined by what you hand it. Nuclear inverts that: it goes looking for music on your behalf, and the plugin layer decides what it finds. The difference in approach is where the uncertainty lives. With VLC, uncertainty is in the file; with Nuclear, uncertainty is in the plugin.

A second comparison is with any hosted streaming service client. Those give you a stable catalogue and a subscription, and in exchange you get ads or a bill, plus telemetry. Nuclear's README explicitly claims no ads and no tracking, and it is AGPL-3.0 licensed, so the client code is inspectable. What it does not offer is a guarantee that any particular track will be available tomorrow.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-09, eight days before this writing. Releases are frequent: [email protected], 1.48.2 and 1.48.3 all landed on 2026-09-04, three patch versions in one day. The README lists auto-updates as a feature, so packaged installs track releases without manual work. The upgrade cost that remains is plugin compatibility, which auto-update does not manage for you.

Building from source carries a heavier cost. The toolchain pins Node.js 22 or newer, pnpm 9 or newer, and stable Rust, and Tauri requires platform-specific system dependencies that the README defers to the Tauri v2 prerequisites page. The package.json declares packageManager [email protected] while the README asks for pnpm 9 or newer, so the declared version is the stricter of the two.

The licence is AGPL-3.0-only, per both the README and the package.json license field. That is a copyleft licence with a network clause. If you fork Nuclear and make it available to users over a network, the AGPL's source-disclosure terms are the thing to read before you ship. This is a description of the licence identifier, not legal advice; the LICENSE file in the repository is the authoritative text.

Editorial conclusion

Adopt Nuclear if you want a desktop player whose sources, metadata and dashboard are all plugin-defined, and you are comfortable installing a Tauri app or running the monorepo from source. Do not adopt it if you need a hosted service, a mobile client, or a guarantee about the legality of any particular stream. Before committing, check the Releases page for your platform's format, open Settings, Integrations and confirm the MCP server binds to 127.0.0.1:8800, and read the AGPL-3.0 LICENSE to see how it applies to anything you distribute.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. nukeop/nuclear on GitHub
3. Project website
4. README
5. Releases