chartr
An approachable agent multiplexer: run your CLI agents in tabbed terminal spaces and plan, track, and finish work on a live star-map.
Evidence shows previously reported localhost trust-boundary issues (cross-origin WebSocket control, DNS rebinding, CORS-simple writes) fixed via strict Origin/Host validation, owner-only state, verified build tooling, publicly credited; CI scoped to contents:read; deb/rpm delegate WebKitGTK security updates to the distro. Deductions: no source or doc demonstrates user-confirmation mechanics for agent-session actions, sensitive-data handling, rollback paths, or the actual external-effects boundary of running PTYs — all score 1.
README and CI are mutually consistent: alpha status, known bugs, and notification-coverage limits are candidly disclosed. Dependency availability is strongly evidenced (the linux-shell-build gate exists because a rotten webkit2gtk-4.0 pin once shipped a version with no Linux app; ConPTY smoke gates the release). Deductions: self_consistency stays at 2 since claims like 'Fixed Claude's spinner' cannot be checked in the provided files, and failure_messages rests only on prose about notification fallback with no code shown.
Audience (heavy CLI-agent users) and scenarios (plan → tickets → context-loaded sessions) are clear, and the known-limits section is exceptional (ticket rendering, zenity/kdialog dependency, notification fallback, Claude status false-idle), earning capability_boundaries a 3. Deductions: trigger_precision is 1 — notification accuracy is self-admittedly dependent on readable transcripts, with screen-derived timing that can fire late or not at all; Windows native app remains best-effort/unshipped.
Information architecture is excellent (README, getting-started, CLI/source builds, ADR directory, SECURITY.md), install notes cover macOS Gatekeeper and per-distro Linux with checksums, known limitations are thorough, MIT license is complete — hence the 3s. Deductions: naming_stability is 1 (alpha, file formats may change, no compatibility promise); examples_and_faq is 1 (no concrete examples in provided files); versioning_changelog is 2 (version and release-notes links but no in-repo CHANGELOG); maintenance_responsibility is 2 (honest one-maintainer-alpha statement but no succession or support arrangement).
Positioned as an agent multiplexer with real marginal value over tmux-plus-scripts: star-map, ticket-context injection, self-titling tabs, at-a-glance status; no hosted service or telemetry lowers ongoing cost. Deductions: all usability evidence is screenshots and prose — this static review executed nothing — and there is no token/resource-consumption data, so cost_benefit stays mid-range.
Most claims are traceable: ADR references, the credited vulnerability report and PR #5, CI comments explaining why each gate exists, and a public postmortem of the v0.2.3 missing-Linux-assets incident; workflows corroborate README claims. Deductions: go 1.26 and several dated pseudo-version dependencies cannot be independently verified in this scope, and several README features (self-titling tabs, canvas renderer) have no corresponding code in the provided files, so all criteria sit at 2 rather than 3.
- macOS builds are unsigned; first launch requires a manual Gatekeeper override, which many enterprise environments prohibit.
- For agents whose transcripts chartr cannot read, completion notifications fall back to screen-derived timing that may fire late or not at all — do not rely on it as a completion signal.
- The Linux folder picker depends on zenity/kdialog; type an absolute path when unavailable.
- Alpha stage: file formats may change before 1.0; do not make it the sole carrier of critical workflows.
- One-maintainer project with no back-porting promise; verify upgrades yourself.
What does this agent do, and when should you use it?
chartr is an agent multiplexer written in Rust, positioning itself as an "AI workspace with a map of your work." It organizes terminal sessions into filterable, reorderable spaces, each containing tabbed sessions where agents and commands run. Its core workflow: plan with an agent, chart the plan onto an interactive star-map, then drive it to completion one ticket at a time — each ticket spawns a session preloaded with the exact context it needs. It lets you register the CLI agents you already use (claude, codex, grok, kimi, pi are explicitly supported for status detection) plus skills from local folders or remote git repositories, and surfaces at-a-glance status, self-titling tabs, and system notifications. The current release is v0.2.4 and the project is still alpha, with features and file formats subject to change before 1.0. It explicitly plans no hosted service or user accounts and sends no telemetry.
chartr ships as a desktop app (macOS dmg, Linux AppImage/deb/rpm) backed by a local server. You register your existing CLI agents and skills (from local folders or remote git repos), then open a space and run agents and commands in tabbed terminal sessions. It reads agent transcripts to detect completion — v0.2.4 accurately reads completion from claude, codex, grok, kimi, and pi transcripts — and shows working/idle/waiting-for-input status, sending system notifications when a session needs you. Tabs self-title from harness titles or the first completed turn, searchable and configurable in Settings. You plan tasks on an interactive star-map, spawn context-loaded agent sessions from tickets, search the active session with Ctrl+Shift+F, drag to reorder sessions, and Ctrl+C or /exit keeps the shell and scrollback open. Terminal appearance and prompts are configurable in terminal.toml and Settings; on Linux the renderer defaults to canvas with a DOM fallback and latency tracking.
- A developer running several CLI coding agents (e.g. Claude Code, Codex) in parallel who wants one view of which sessions are working, idle, or blocked.
- An engineer following a plan-then-execute method: draft a plan with an agent, visualize it as a star-map, and complete tickets one at a time via context-loaded sessions.
- A developer in a monorepo or multi-project setup who needs terminal sessions grouped into filterable, reorderable spaces by folder.
- A user who wants system notifications when long-running agent work completes or needs input, instead of polling.
- A team reusing an existing skills library, registering skills from local folders or remote git repositories without migration.
- A privacy-conscious individual developer who refuses hosted services, accounts, or telemetry.
What are this agent's strengths and limitations?
- Agent-agnostic by design: register and drive the CLI agents you already use (claude, codex, grok, kimi, pi), with no single-vendor lock-in.
- The star-map workflow is a concrete differentiator: visualize the plan on an interactive map and spawn context-loaded sessions per ticket.
- Accurate completion notifications by reading agent transcripts (claude, codex, grok, kimi, pi in v0.2.4), paired with self-titling, searchable tabs.
- Explicit privacy stance: no hosted service, no accounts, no telemetry, ever.
- Well-rounded Linux distribution (AppImage, deb, rpm) plus macOS Apple silicon builds, and ADR documents explaining design decisions.
- Still alpha at v0.2.4; the README states features and file formats may change before 1.0, creating migration risk.
- No Windows desktop app yet — the WebView2 shell is packaged but untested; this is a named platform blocker.
- The Linux folder picker depends on zenity or kdialog; without them you must type absolute paths manually.
- Agents whose transcripts chartr cannot read fall back to screen-derived timing, so notifications can fire late or not at all; Claude still reports idle while waiting on non-permission selectors.
- Known bugs: ticket details Markdown renders uncleanly and clicking a ticket reference does not open that ticket.
How do you install or deploy this agent?
macOS (Apple silicon): download https://github.com/rengwu/chartr/releases/latest/download/chartr_darwin_arm64.dmg. The app is unsigned; if blocked on first launch, open chartr, click Done, then go to System Settings → Privacy & Security → Security → Open Anyway. Linux AppImage: chmod +x chartr_linux_amd64.AppImage && ./chartr_linux_amd64.AppImage (arm64 available; WebKitGTK is bundled). Debian/Ubuntu 24.04+ or Debian 13+: sudo apt install ./chartr_linux_amd64.deb (uses distro WebKitGTK). Fedora: sudo dnf install ./chartr_linux_amd64.rpm. CLI usage and source builds are documented in docs/cli-and-source-builds.md.
How do you use this agent?
After launching: 1) register the CLI agents you already use and register skills from local folders or remote git repos; 2) register a folder as a space (type its absolute path if no zenity/kdialog is available on Linux); 3) open the space and run agents and commands in tabbed terminal sessions; 4) plan with an agent, chart a star-map of the work, then spawn a session from each ticket with the relevant context preloaded; 5) watch the status indicators (working/idle/waiting for input) and respond to system notifications. Customize terminal appearance and prompts via Settings and terminal.toml; use Ctrl+Shift+F to search the active session.
How does this agent compare with similar options?
The README explicitly relates chartr to herdr (ogulcancelik/herdr) — the agent multiplexer that inspired it, running in the terminal instead of a window. Choose herdr for a terminal-native experience; choose chartr for a graphical star-map and ticket-driven workflow. wayfinder-maps is the author's standalone read-only map CLI where the star-map originated.