Nezha (hanshuaikang/nezha): a Tauri IDE for running Claude Code and Codex sessions across projects

The problem Nezha targets: parallel agents, one attention span

The README is blunt about the premise. Traditional IDEs were designed around a human writing code, so plugin systems, refactoring and autocomplete exist to make typing faster. Nezha's argument is that AI now writes more of the code, and that writing code has become something you can do in parallel. The bottleneck moves from keystrokes to attention: how do you track tasks across several projects when five agents are running and only one of them needs you?

That framing decides the audience. This is not a general-purpose editor for someone who writes every line by hand. It is for a developer who keeps two to five repositories open, hands work to Claude Code or Codex in each, and currently pays for that with a wall of terminal tabs and a lot of alt-tabbing. The README states the installer is 7 MB, which matters if you resent launching a heavy Electron IDE just to approve a diff.

One caveat about the name: the repository is hanshuaikang/nezha, and searching for it returns a large amount of unrelated material about the Chinese deity and the animated films. Searching "Nezha" alone will not find this project. The homepage given in the repository metadata is nezha.hanshutx.com.

Agent-first architecture: Tauri shell, xterm.js terminal, CodeMirror editor

The stack is visible in the repository layout. The front end is TypeScript and React under src/, built with Vite; the desktop shell is src-tauri/, and the acknowledgements credit Tauri for building smaller desktop applications. The terminal is xterm.js, listed in the same acknowledgements, and the editor is CodeMirror: package.json carries @codemirror packages for cpp, css, go, html, java, javascript, json, markdown, python, rust, sql, vue, xml and yaml, plus legacy modes and the github theme. That list tells you what syntax highlighting to expect, and it also tells you what kind of editor this is. CodeMirror is a component, not a full IDE engine, so the README describes a lightweight editor rather than a refactoring tool.

The agent integration is the part that carries the design. The README says Nezha embeds the native Claude Code and Codex CLI in its terminal rather than reimplementing an agent protocol. Sessions are discovered and then rendered visually after they end, so a finished run is not lost behind a resume command. Notifications fire when Claude Code or Codex needs human input, using an in-app message and an application badge. Git and Git Worktree are integrated at the application level, and there is a Skill management screen that the README says manages local skills through symlinks. The data flow is therefore: your repository on disk, an agent CLI running in a real terminal, Nezha reading and presenting the session record, and Git operations layered on top of the same working tree.

Installing Nezha and starting a first multi-project session

The README gives one prerequisite: install Claude Code or Codex before using Nezha. Distribution is through the releases page, and the project publishes versioned builds; the most recent listed release is v0.4.7 from 2026-08-01. On macOS the README warns that the first launch shows the message that Nezha is damaged and should be moved to the trash, and attributes this to the package not being signed. The documented fix is a single command:

xattr -rd com.apple.quarantine /Applications/nezha.app

After that, launching the app should open the workspace view rather than the Gatekeeper warning. The next step is adding a project. The README describes a project sidebar on the left for switching between workspaces, and a right sidebar for moving between projects quickly. There is no documented CLI or config file for registering a project, so the first real use is a UI action: add a repository you already work in, and Nezha will look for existing Claude Code and Codex sessions in it.

If you want to build from source instead of using a release, the repository uses pnpm and exposes Tauri through the package scripts. The standard sequence a contributor would run is:

pnpm install
pnpm tauri dev

That starts the Vite front end and the Tauri shell together for development. The package also defines lint, format and test scripts, with vitest as the test runner and eslint configured to fail on any warning. None of this is documented as an end-user install path in the README; it is the contributor route implied by package.json.

Where Nezha stops being the right tool

The limitations follow directly from the CodeMirror choice and the README's own wording. There is no language server, no debugger and no refactoring engine described anywhere in the documentation. If your day involves stepping through a stack trace or renaming a symbol across a monorepo, you will still open a full IDE. Nezha is positioned as the place where you dispatch work and review it, not where you do deep surgery on a codebase.

The macOS signing situation is a real friction point, not a footnote. The README documents the quarantine workaround because the package is unsigned, which means every new install on macOS requires the same command, and users in managed environments where Gatekeeper policy is enforced may not be able to run it at all. The README does not document an auto-update mechanism, so upgrades appear to mean downloading a new release.

There is also a dependency you cannot route around: Nezha is a front end for Claude Code and Codex, not a replacement. If those CLIs are not installed and authenticated, the application has nothing to drive. And the session features depend on reading agent history from disk. The README does not describe what happens when a session is started outside Nezha, or whether a corrupted or missing history file degrades the session view. That is the kind of edge case worth checking against your own setup before you rely on it.

How Nezha differs from Cursor and from a terminal multiplexer

The obvious comparison is Cursor. Cursor is a fork of VS Code with AI editing built into the editor buffer: you select code, the model rewrites it, and the surrounding IDE machinery (extensions, language servers, debugging) is still there. Nezha inverts that. The agent is the primary unit and the editor is a lightweight viewer, which is why the README calls it Agent-first and why the editor is CodeMirror rather than a VS Code core. If your work is mostly inline edits inside one file, Cursor's model fits better. If your work is dispatching tasks across repositories and reviewing the results, Nezha's model fits better.

The second comparison is a terminal multiplexer such as tmux, which many people already use for exactly this problem. tmux gives you persistent sessions across panes and costs almost nothing. What it does not give you is a rendered view of a finished agent session, a notification when an agent blocks on a question, or Git and worktree operations in the same window. Nezha's value is that layer, not the terminal itself. If you are comfortable with tmux and do not need session playback or in-app Git, the added application is not obviously worth it.

Licence, maintenance and the cost of upgrading Nezha

Nezha is GPL-3.0. That is a copyleft licence, and it matters if you plan to fork the application, bundle it into a commercial product, or ship a modified binary. The GPL requires derivative distributions to be licensed under the same terms and to make source available. Using Nezha as a tool to write your own code does not put your code under the GPL, but modifying and redistributing Nezha does carry obligations. This is a general description of the licence, not legal advice; check the LICENSE file in the repository and talk to counsel if you intend to redistribute.

On maintenance, the repository is not archived and the last push was on 2026-09-10, eight days before this writing, so the project is being changed. The release cadence visible in the metadata is roughly every two to four weeks across v0.4.5, v0.4.6 and v0.4.7 between early July and early August 2026. Upgrading costs whatever the new release changes, and because the README documents no auto-update path, plan on a manual download. The build is Tauri rather than Electron, which is why the installer is small, but it also means the project depends on the Rust side under src-tauri/ and on the Tauri plugin versions pinned in package.json. A contributor building from source inherits that toolchain as well as the Node one.

Editorial conclusion

Adopt Nezha if you already run Claude Code or Codex on more than two repositories and lose track of which session is waiting on you; it is a poor fit if you want a full IDE with refactoring and debugging, or if you cannot accept an unsigned macOS build. Before committing, install Claude Code or Codex first, run the xattr command on macOS, and confirm that the session discovery picks up your existing .claude and Codex history rather than only sessions started inside Nezha.

Frequently asked questions

Official sources

1. hanshuaikang/nezha on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases