MuLiuSaMa/NexBox: a Windows game toolbox built on Tauri, Rust and an embedded HTTP server

A desktop app with an embedded HTTP server and a C# helper process

The architecture is a Tauri v2 shell with a React and TypeScript frontend over a Rust backend, and two details in that stack are worth surfacing. The backend includes Axum with Tower described as an embedded HTTP service, which means the desktop process opens a network listener rather than being purely local in the way a single-window utility normally is. Monitoring is delegated rather than implemented: LibreHardwareMonitorLib is described as a C# monitoring helper process, and a compiled `LibreHardwareMonitorLib.dll` sits at the top of the repository alongside a `monitor/` directory. Native hardware access goes through NVML Wrapper for NVIDIA telemetry and WMI or sysinfo for Windows hardware information, with `windows-sys` and `winreg` used for deep integration into the registry, system services and Bluetooth. A `.gitmodules` file at the root indicates at least part of this is pulled in as a submodule.

The local-only claim is contradicted by six other features

One of the advertised highlights states that core functions need no network and that no private data is uploaded, and the deployment section repeats the purely local framing. Several documented features sit awkwardly against that. One reads a daily code directly out of game memory. The music player supports logging into platform accounts to retrieve full playlists, which is an outbound credential flow to two music services. The in-game overlay lists a password field sourced from the running game. The gun-code browsing feature includes liking and submitting entries, which is a social write path. Auto-update checks for a new version at startup and installs it from inside the application. And the Delta Force section ships shortcuts to several external code and lookup sites. Each could be argued individually; taken together they make the blanket local claim hard to reconcile with the feature list.

Three packaging targets and three distribution mirrors

Build output is not a single artefact. The scripts define a normal Tauri desktop build, a second variant driven by a separate Tauri configuration file with a build mode named for a store, and a third that produces an MSIX package through PowerShell scripts. Both of the packaging scripts invoke PowerShell with the execution policy bypass flag, which suppresses the machine's script policy for those two commands. The documented build sequence is four steps:

git clone https://github.com/MuLiuSaMa/NexBox.git
cd NexBox
npm install
npm run tauri:dev
npm run tauri:build

Distribution mirrors the same plurality: alongside the GitHub releases there are release pages on Gitee and GitCode, which is a sensible hedge for a Windows tool aimed at users whose network makes one host slow. The stated requirements are Windows 10 version 22H2 or later on 64-bit only, 4 GB of memory suggested, and 200 MB of disk. Version 9.9.3 in the manifest matches the newest tag, so the two do not drift.

Two lockfiles and two ESLint configurations coexist

Two dependency lockfiles are committed at the top level, a npm lockfile and a Bun lockfile, while every documented build instruction uses npm. That leaves two resolved dependency trees for one project and no statement about which one is authoritative, so a build can differ depending on which package manager reaches the tree first. The lint configuration is duplicated in two formats as well, with both a legacy ESLint configuration file and a flat-config module, while the lint script is a plain call over the whole directory. A husky prepare hook installs the pre-commit machinery, and the engineering notes pair it with Prettier and ESLint so formatting is checked before commit. The continuous integration setup is described as running frontend lint and build alongside a Rust cargo check, so both halves of a Tauri project are covered but the frontend half runs through whatever ESLint resolves from two configs.

The optimisation list reaches into Windows update and Defender

The system tuning section is described as more than twenty tools, and several of them alter machine state in ways that outlive the application. One category pauses Windows updates, disables automatic updating and blocks driver updates. Another, presented as a general optimiser covering fifty-plus adjustments across six areas including privacy, includes entries specifically for Windows Defender. Startup management scans the registry and the startup folder and offers to begin minimised at boot. A separate entry tunes the process priority and CPU affinity of a named commercial anti-cheat engine, with automatic background detection. Others cover page file limits, assigning processes to performance or efficiency cores, defragmentation and TRIM, shader cache clearing, importing high-performance power plans, DNS presets with TCP tuning, and USB polling rate adjustment. These are declared capabilities rather than instructions, and each one is a durable system change.

Hardware monitoring wraps three libraries and reads SMART data

Telemetry comes from three layers: the C# LibreHardwareMonitor helper, NVML for NVIDIA-specific readings, and WMI or sysinfo for the Windows side. What gets surfaced is broad. For the processor, usage, temperature, frequency, voltage, power and core topology. For the graphics card, usage, temperature, fan speed, power, clocks, memory consumption and driver version. Memory covers physical and virtual usage with working set size. Disks report per-partition used and total space, SMART health and interface type, with a separate disk health feature that reads SMART and evaluates status and temperature. The motherboard, display, frame rate and network each get their own row, including link speed and latency. Multiple GPUs can be shown at once, trend sparklines are included, and reports export as text or JSON.

Forty-six feature pages across six languages

The frontend is described as React 19 with TypeScript 5.8 built by Vite 6, with Chakra UI and Emotion for components, Zustand for state, React Router 7 for routing, i18next for internationalisation, Framer Motion for animation, DnD Kit for drag ordering and three.js for 3D rendering. The source tree lists a pages directory holding 46 feature pages or panels, plus separate directories for components, React contexts, custom hooks, stores, utility code, locales, assets, configuration and type definitions. Internationalisation covers six languages: Simplified Chinese, Traditional Chinese, English, French, Japanese and German. A lunar calendar library appears among the runtime dependencies, which is consistent with a feature set that includes date and almanac style calculations. Theme customisation covers dark and light modes, a custom accent colour, frosted glass effects and video wallpaper, with a system tray mode and a configurable close behaviour.

The overlay layer ships named crosshair presets

Display enhancement is where the feature set turns toward the overlay, and the crosshair tool is the most specific of them. It offers six styles including cross, dot and circle, accepts a custom PNG as the reticle, includes a colour picker, and ships preset reticles attributed to named professional players. Around it sit several HUD layouts: a draggable in-game panel with reorderable metrics, a style variant resembling a dynamic island, a vertical panel intended for a second monitor, and a top bar pinned above other windows. Alongside those are a colour filter with independent temperature, brightness, contrast and saturation controls, RGB gamma adjustment, ICC profile management and per-monitor calibration, plus an automatic clicker with a configurable rate and hotkey, and a registry-level change that rewrites the GPU name shown in the operating system. Global hotkeys bind the overlay, the panel and the filter.

Editorial conclusion

This is not suitable for running on a machine you use for online play. The bundle includes memory-reading, automated input, registry rewriting and crosshair overlay features, and the project itself notes that tools in this category are misidentified by anti-cheat software, so account risk is a real consequence of installation rather than a hypothetical one. If you want the monitoring and display-calibration halves, extract those ideas rather than running the whole box, and treat the local-only claim as unverified given the embedded HTTP listener and the account and auto-update features it ships alongside.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MuLiuSaMa/NexBox on GitHub
4. README
5. Releases