chartr: a desktop agent multiplexer that turns a plan into a ticket map
Agent multiplexer with spaces, panes, and plugins
At a glance
- What is it?
- chartr is an MIT-licensed, Go-based desktop app that groups terminal sessions into spaces and drives work ticket by ticket from an interactive star-map. It is alpha software with an unsigned macOS build, no Windows app yet, and notification accuracy that depends on the agent's transcript.
- Who is it for?
- Adopt chartr if you already run several CLI agents by hand and want them grouped into spaces with a map over the top, and if you are on Apple silicon or Linux amd64/arm64 and accept an unsigned macOS build. Skip it if you need Windows, if you depend on notifications for agents whose transcripts chartr cannot read, or if you want a stable file format before 1.0.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem chartr targets: a plan that never reaches the terminal
Most people who work with CLI coding agents end up with the same shape of day. A plan is written somewhere, then a terminal is opened, a prompt is retyped, a second terminal is opened for the next piece, and the plan drifts out of sync with what is actually running. chartr's answer is to make the plan the control surface. The README describes the loop directly: plan with an agent, chart a map of your work, drive the map to completion one ticket at a time, and let each ticket spawn a session with the context it needs. The audience is anyone already running agent CLIs and willing to register them rather than have them bundled. It is not a model, not a hosted service, and not a wrapper around one vendor's agent. The README states plainly that no hosted service or user accounts will ever be planned, and that chartr sends no usage data or telemetry. That positions it against cloud agent dashboards, and it also means the app has to do its work locally against whatever CLIs you point it at.
Spaces, panes and the star-map: the actual mechanism
Terminal sessions are grouped into spaces, and the README describes folders as spaces, which suggests a space is anchored to a directory rather than being an abstract container you name. Sessions within a space can be filtered and reordered, and v0.2.4 added drag-to-reorder for session rows. On top of that sits the star-map, described as a live visualization of the plan with progress tracked on an interactive map. A ticket is the unit that connects the two: selecting one spawns a session preloaded with that ticket's context. Tabs name themselves from the agent's own session, so a row of tabs reads as the work rather than as a list of shell numbers. Status is derived rather than declared. v0.2.4 reads completion from agent transcripts for claude, codex, grok, kimi and pi, and the app surfaces working, idle and waiting-for-input states. The word panes in the project description matters: the roadmap lists browser, source control, code review and token usage panes as future additions alongside maps, so maps are currently the pane type that exists. Plugins and skills are registered from local folders or remote git repositories, which is how the map side connects to the /wayfinder skill the acknowledgements credit.
Installing chartr and the config surface you actually touch
There is no build step for a normal install. The README points at a macOS disk image for Apple silicon and a Linux AppImage for amd64 or arm64, plus deb and rpm packages. The macOS build is unsigned, and the README walks through the workaround: launch, click Done when blocked, then System Settings, Privacy & Security, Security, Open Anyway. On Linux the AppImage needs a chmod before it runs, and WebKitGTK is bundled inside it. The native packages take the opposite approach and use the distribution's WebKitGTK so security updates arrive through apt or dnf, with Ubuntu 24.04+ or Debian 13+ required. The one configuration file named in the README is terminal.toml, used to select the terminal renderer: Linux defaults to canvas, with a DOM fallback and latency tracking. Tab titling is configured in Settings, and Ctrl+Shift+F opens find within the active session. Source builds and server-only usage are documented separately in docs/cli-and-source-builds.md rather than in the README, so anyone wanting to run chartr as a headless server has to follow that document. There is no built-in updater yet; it is listed as still to come, so upgrades mean downloading a new release.
Where chartr breaks: transcript coverage, the folder picker, and alpha file formats
The README is unusually direct about failure modes, and two of them are structural. First, notification accuracy is bounded by transcript access. Completion is read from transcripts for five named agents; for anything else chartr falls back to screen-derived timing, which the README says can fire late or not at all. If your agent is not in that list, the at-a-glance status is a heuristic, not a fact. Second, the folder picker is raised by the server process, so on Linux it needs zenity or kdialog installed, and on Windows it is unavailable entirely. Where neither exists, the documented workaround is to type an absolute path to register a space. That is a rough edge on a core flow. There are also admitted bugs: ticket details do not render markdown cleanly, clicking a ticket reference does not open that ticket, and Claude reads as blocked on its permission prompt while still reporting idle while it waits on other selectors. The status bug is the one to weigh most heavily, because status is the feature that justifies the map view. Finally, the README states chartr is still alpha and that features and file formats may change before 1.0. If your workflow writes map files you expect to keep, that warning applies to you.
herdr and the terminal-native alternative
The README names its own ancestor: herdr, described as the agent multiplexer that inspired chartr, in your terminal instead of a window. That is the real fork in the road, and it is not a feature comparison so much as a placement question. herdr lives inside the terminal you already have, which means it inherits your existing multiplexer keybindings, your scrollback, your SSH sessions and your remote setup, and it imposes no WebView runtime. chartr takes the opposite bet: it ships as a desktop application with a WebKitGTK or WebView2 shell, and spends that cost to get a visual map, drag-reorderable session rows, system notifications and a settings UI. If you work over SSH on a remote box, a desktop window with a bundled browser engine is the wrong shape entirely. If your work is a plan of twenty tickets and you want to see progress spatially, a terminal multiplexer gives you nothing comparable. The wayfinder-maps project is the other related piece: a read-only map CLI and viewer that the README calls where the star-map started, which implies the map format has an independent life outside the app.
Licence, maintenance and what upgrading costs
chartr is MIT-licensed, which permits commercial use and modification with attribution and no warranty, though the specifics of your situation are a matter for your own counsel rather than this article. The release cadence visible in the material is roughly weekly through August 2026: v0.2.2 on the 3rd, v0.2.3 on the 12th, v0.2.4 on the 20th, with the repository's last push in early September 2026. That is an active pre-1.0 project, which cuts both ways. Fixes arrive quickly, and so do changes. Because there is no built-in updater, every upgrade is a manual download from the releases page, and on macOS that means repeating the Gatekeeper bypass each time unless you keep the app in a location the system already trusts. The AppImage path is the cheapest to maintain since WebKitGTK is bundled and upgrades are a file swap, while the deb and rpm paths trade that for distribution-managed WebKitGTK security updates and a minimum OS version. The unsigned macOS build is a maintenance cost in itself, not a one-time annoyance, since the README's Open Anyway steps are per-install.
Who should adopt chartr now, and what to check first
The fit is narrow but real: you run claude, codex, grok, kimi or pi as your daily agents, you work on a machine you control rather than over SSH, and you already think in terms of a plan broken into discrete pieces. In that case the ticket-to-session spawn is the feature that saves the most typing, and transcript-based completion is the feature that makes the map trustworthy. The misfit is equally clear. Windows users are told the desktop app is coming soon, so there is nothing to adopt. Anyone whose agent is outside the five named CLIs should assume status is approximate. Anyone who needs stable on-disk formats should wait for 1.0, since the README says they may change. Three things are worth confirming before you commit a real project: that the agent you use most appears in the transcript list, that zenity or kdialog is present if you are on Linux, and that the ticket detail bugs will not block you, given that markdown renders poorly and ticket references do not open. If the map is the reason you are interested and ticket navigation is broken, you are adopting the app for a view that does not yet fully work.
Editorial conclusion
Adopt chartr if you already run several CLI agents by hand and want them grouped into spaces with a map over the top, and if you are on Apple silicon or Linux amd64/arm64 and accept an unsigned macOS build. Skip it if you need Windows, if you depend on notifications for agents whose transcripts chartr cannot read, or if you want a stable file format before 1.0. Verify first that your agent CLI is one of the five with transcript-based completion (claude, codex, grok, kimi, pi), and check whether zenity or kdialog exists on your Linux box, since the folder picker will not open without one.
Community notes