# chartr v0.3.0 swaps a Go rewrite for Rust, GPUI and a pinned Zed terminal

> chartr is a native desktop workspace for keeping project terminals, CLI agents and plugin panels in one place, and the stable release is a Rust rewrite built on GPUI with Zed's terminal model. What you get is durable sessions and an HTML plugin surface; what you give up is Windows and any chance of linking it into closed-source software.

**rengwu/chartr** — Agent multiplexer with spaces, panes, and plugins

- Repository: https://github.com/rengwu/chartr
- Website: https://chartr.dev
- Stars: 343 · Forks: 20
- Language: Go
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/rengwu-chartr

## The stable release is Rust while the repository still answers to Go

chartr is listed as a Go project, and the reason is that it was one. The GitHub language field has not caught up with the code, because v0.3.0 is a rewrite rather than an update. That release, published on 2026-09-19, is the stable Rust release for macOS and Linux, and two release candidates preceded it on the same day, v0.3.0-rc.1 and v0.3.0-rc.2.

The older build is not deleted. v0.2.4 stays available for anyone still on what the README calls the legacy Go and Svelte app, which means two generations of the product exist side by side and only one of them is the current design.

The v3 workspace makes the switch concrete. It declares edition 2024, rust-version 1.95, version 0.3.0, and a licence of GPL-3.0-or-later, and there is a rust-toolchain.toml and a Cargo.lock at the root beside a vendor/ directory. The README describes the result as an open-source native desktop app built with Rust and GPUI, and states plainly that it runs locally and needs no chartr account.

## Nine crates, and only the window crate names GPUI

The workspace header in Cargo.toml is the fastest way to understand the shape, because it names each crate's boundary in a comment before naming the crate itself. chartr-storage handles atomic file publication. chartr-agent holds shared provider identity and capabilities. chartr-herdr is a private Herdr transport and lifecycle. chartr-conversations provides provider history with read-only metadata and log adapters. chartr-plugin is the native and manifest authoring contract, chartr-plugin-host does discovery and runtime isolation, and chartr-companion is a retained transport that is excluded from the desktop app.

Then the rule that makes those boundaries worth having: only chartr names GPUI's platform backend as a direct dependency. The final member of the list is the window and the pinned Zed terminal and editor host.

That single sentence is a build-graph constraint, not a comment. It means the eight crates beneath the window can be exercised without a display server, which is the only reason a workspace this size can plausibly carry tests. It also means any change to how the app is hosted belongs in one crate rather than rippling upward.

## One pinned Zed revision supplies the whole terminal

The workspace dependency section explains the Zed layer, and the copy of Cargo.toml shipped with the repository stops partway through that comment, so the exact revision is not spelled out there. What is clear is the shape of the arrangement: a single pinned Zed revision supplies the framework, the platform, the UI and theme, and the full terminal model and view. Keeping the terminal pair at the same revision is what gives chartr Zed's emulator, rendering, input and selection behaviour.

The vendor/ directory at the repository root holds that upstream source, and the workspace excludes five of its subtrees from the member list: vendor/herdr/.build, vendor/zed-platform/gpui_linux, vendor/zed-platform/gpui_macos, vendor/zed-platform/ui, and vendor/zed-terminal-view. Each of those is a Cargo project of its own, and excluding them stops the workspace resolver from treating upstream checkouts as members.

This is the design decision with the longest tail. chartr is not a tmux client with a nicer frame; it embeds somebody else's terminal emulator and inherits its bug list. The trade runs the other way too, which is that you get a real terminal rather than a PTY wrapper around a shell that happens to look like one.

## Herdr holds the processes, a closed tab ends them

Durable sessions are the feature that distinguishes this from a tabbed terminal, and the mechanics are stated rather than implied. Herdr keeps terminal processes alive by default. Quit chartr and the work keeps running. Reopen and your sessions and layout come back.

The boundary is equally explicit: closing a terminal tab ends that session. So there are two different exits, and they mean opposite things. Quitting the window suspends; closing the tab terminates. That is a reasonable default, and it is also a footgun for anyone who assumes a close button is a hide button.

The rest of the workspace model is built on that. Sessions group into spaces by folder, with Free sessions for work that belongs to no project. Tabs move, split into columns or rows, and group terminals and plugin tools inside a space, and you can switch between Tabs, Spaces and Chats views with the pane arrangement intact. Wayfinder adds a live map of the work, ticket review, and launching an agent with the context it needs. Registered CLI agents launch with your own arguments, environment and prompts rather than a preset.

## Plugins are HTML, CSS and JavaScript beside a native shell

The plugin story is the most unusual thing here. A native Rust and GPUI application ships bundled plugins that are written in HTML, CSS and JavaScript, and you can install more or write your own. The shipped ones browse pages, reuse prompts and manage skills. The repository keeps both a plugins/ directory and an examples/plugins/ directory, which is where the contract is demonstrated rather than described.

Two crates enforce the boundary. chartr-plugin defines the authoring contract for native and manifest plugins, and chartr-plugin-host handles discovery and runtime isolation, which is the part that decides what a plugin is allowed to reach.

Compare that with tmux, which is the obvious rival for the session half of the job. tmux gives you surviving sessions with far less machinery, and it will run anywhere a terminal runs. It has no project folders, no agent registry, no way to open an HTML panel next to a pane, and nothing to configure plugins in. chartr buys the panel and the agent registry with a pinned upstream dependency tree and a native build.

## The licence is inherited, not chosen

chartr is GPL-3.0-or-later, and the workspace comment gives the reason rather than leaving you to infer it: Zed's ui and theme are GPL-3.0-or-later and chartr links them directly, so chartr is too. The reasoning is filed as docs/adr/0002, which is where to read the decision rather than the summary of it.

That is a licence consequence with teeth. chartr runs locally and needs no account, which is the part most people care about, but linking it means the copyleft obligation travels with it. Anyone embedding it in a product they distribute has a question to answer that is a legal one, not an engineering one, and this repository gives you the pointer to the reasoning but not the advice.

The same applies to the vendor tree. If a future Zed revision changes its own licence, chartr's does not change with it automatically, but the build will tell you quickly because the link either compiles or does not. Check the ADR before you assume the licence question is settled.

## macOS and Linux, and an install the README will not print

The README links installation to docs/installation.md, getting started to docs/getting-started.md and documentation to docs/README.md, and it does not print the commands on its own page. So if you are looking for a one-liner here you will not find one. The repository is at github.com/rengwu/chartr and the project site is chartr.dev, and the release tags v0.3.0 and v0.2.4 are where binaries are named.

Platform coverage is narrower than the packaging directories suggest. v0.3.0 is stated as the stable release for macOS and Linux, and Windows is not named anywhere in the release note or the feature list. The packaging/ directory exists, but what it contains is not something the README explains.

Two acknowledged defects tell you what to expect from a project at this stage. One contributor privately reported vulnerabilities that hardened the original implementation's localhost trust boundaries, which is worth knowing before you point the app at anything sensitive. Another reported an issue that led to improvements when opening chartr from monorepo subdirectories.

## Four sibling projects, and where the star map started

The README credits four projects instead of hiding them. Zed supplies GPUI, the UI components, the themes and the terminal stack that chartr builds on. Herdr, credited separately, is the persistent terminal session layer, and chartr wraps it in its own crate as private transport and lifecycle, which is how the persistence feature stays separable from the window.

Then there are two that are less borrowed than shared. wayfinder-maps is the map CLI and viewer where the star-map started, and mattpocock/skills is where the original /wayfinder skill and workflow came from. The Wayfinder feature in the app, the live map of your work with ticket review and context-aware agent launches, is the descendant of those two rather than a Zed feature.

That lineage explains the shape better than a feature list would. chartr is a desktop shell for agents that other people wrote, plus a terminal that survives the shell closing. If you only need the second half, Herdr on its own is a fraction of the build. If you need both in one window with an HTML panel beside them, this is the tool, on macOS or Linux, under GPL-3.0-or-later.

## Conclusion

chartr fits a developer who runs several coding agents at once and wants their terminals to survive quitting the app, and who is willing to live on macOS or Linux with a GPL-3.0-or-later binary. It does not fit a Windows workstation, a team shipping proprietary desktop software, or anyone who needs a documented one-line install, because the README points at docs/installation.md rather than printing the commands. Before you commit, check two things: whether the pinned Zed revision in the vendor directory still builds against your rust-version 1.95 toolchain, and whether Herdr's process persistence matches what you assumed a terminal tab does.

## FAQ

### Is chartr open source and does it need an account?

chartr is open source under GPL-3.0-or-later and runs locally. The README states that it does not require a chartr account.

### Which platforms does the chartr v0.3.0 release support?

v0.3.0 is the stable Rust release for macOS and Linux. The earlier v0.2.4 remains available for users of the legacy Go and Svelte app.

### What does Herdr do for chartr sessions?

Herdr keeps terminal processes alive by default, so quitting chartr leaves work running and reopening restores your sessions and layout. Closing a terminal tab ends that session.

### How do chartr plugins work?

Bundled plugins browse pages, reuse prompts and manage skills, and you can install more or build your own with HTML, CSS and JavaScript. The authoring contract sits in the chartr-plugin crate and discovery and runtime isolation sit in chartr-plugin-host.

### Why is chartr licensed GPL-3.0-or-later?

Zed's ui and theme are GPL-3.0-or-later and chartr links them directly, so chartr takes the same licence. The workspace comment in Cargo.toml records that, and points at docs/adr/0002 for the decision.

## Sources

- [License: MIT](https://github.com/rengwu/chartr/blob/main/LICENSE)
- [Project website](https://chartr.dev)
- [README](https://github.com/rengwu/chartr/blob/main/README.md)
- [Releases](https://github.com/rengwu/chartr/releases)
- [rengwu/chartr on GitHub](https://github.com/rengwu/chartr)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rengwu-chartr