# Ghostex: a desktop workarea for running several CLI agents at once > Ghostex is a Rust/GPUI desktop app that keeps Claude Code, Codex, OpenCode and other agent CLIs in one workspace, with a client/server split that lets a phone or a TUI attach to the same sessions. It is early software with a beta Windows path, and the README is honest about which parts are still rough. **maddada/Ghostex** — Ghostex is an extensible platform for building AI workflows and agent integrations with practical deployment-oriented tooling. - Repository: https://github.com/maddada/Ghostex - Website: https://ghostex.dev - Stars: 844 · Forks: 44 - Language: Rust - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/maddada-ghostex ## The problem Ghostex targets: too many agent terminals, no shared context Running one CLI agent is easy. Running four of them across two machines is not. Each agent keeps its own session history, its own scrollback, and its own idea of which directory it is working in. When you want to hand a task from Claude Code to Codex, you copy output by hand. When you want to find the prompt you wrote three days ago, you grep shell history and hope. Ghostex is built for that specific situation. The README describes it as a native desktop app for Claude Code, Codex, OpenCode and any other CLI agent, where you run them side by side and review their work. It is aimed at developers who keep multiple agents and terminals alive at once, not at someone who occasionally runs a single coding assistant. The scope is deliberately wide: Ghostty terminals, a Rust/GPUI interface, embedded Chromium panes, and mobile session access all sit in one workspace. The secondary audience is people who want remote control without a remote desktop. The README states that the client/server split lets you install just the gxserver daemon on a remote machine and then control the agents on that machine from any client device. Supported clients are listed as macOS, Linux, Windows WSL2 beta, Android and a TUI based on herdr. Supported hosts are macOS and Linux, tested on Ubuntu x64 and arm64. That list is narrower than the client list, and it is the first place a prospective user should check their own setup against. ## How the client, gxserver and zmx layers fit together The architecture is three layers, and the README names them in a parenthetical: client apps, gxserver daemon, zmx persistence. The clients are the desktop app, the Android app, the iOS TestFlight build and the TUI. The gxserver daemon is the piece that actually owns the agent processes on a host. zmx is the persistence layer underneath, which is what makes a session survive a client disconnect. That split explains most of the product's behaviour. Because the daemon holds the sessions, a phone can attach to a session that started on a laptop. Because the client is separate, the same session can be rendered two ways: the README describes toggling between a terminal rendering and a chat GUI for the same session with a single hotkey. The chat view exists because, in the README's words, you cannot click images in a terminal and editing long prompts is awkward, while the terminal remains more powerful and gets features first. Cross-agent orchestration sits on top of the same command surface. The README says agents can launch other agent sessions using the "ghostex" cli command, and gives the example of asking Claude Code to launch Codex sub-agents, send prompts to them and read their output. There is a /ghostex-cli skill for writing your own. A Kanban board built on beads is described as the place to collect thoughts, with an orchestrator agent managing subagents against them. One caveat on the README itself. Several feature blurbs are clearly unfinished prose, including a sentence about the built-in IDE that reads "Sleeps when not in use to same resources (configurable)". The intent is legible, the resource-saving claim is not, and nothing in the repository files I can see quantifies it. Treat that claim as unverified. ## Installing Ghostex on macOS, Linux and Windows macOS is the shortest path. The README gives a Homebrew cask that installs the Apple Silicon build, and notes a DMG download as the alternative. ```bash brew trust maddada/tap && brew install --cask maddada/tap/ghostex ``` On Linux there are DEB, RPM and Arch tarball downloads, plus a portable tarball on the latest release. That portable build is a prefix-preserving tree, so the README instructs extracting it at the filesystem root, which installs /opt/ghostex and puts ghostex and gx on your PATH. ```sh sudo tar -xpf ghostex-*-linux-x64.tar.zst -C / ghostex ``` The README lists runtime dependencies for Arch, including gtk3, nss, nspr, mesa, libxkbcommon, alsa-lib, at-spi2-core, libcups, libdrm, libxcomposite, libxdamage, libxrandr, libxshmfence, pango, cairo, fontconfig and wmctrl. Two constraints are worth reading twice. Ghostex does not bundle Chromium, and the first GUI launch downloads the browser runtime into your cache directory, so a machine behind a restrictive proxy will fail at first start rather than at install. And the tarball must go to the root, not to a home directory, or the PATH entries will not land where the README says they do. Windows is explicitly a beta. The README says the Windows app is intended for WSL2 workflows only, may still have bugs, and that native Windows shell workflows are not the intended setup. Ghostex manages its terminals, gxserver and Source editor inside the selected WSL2 distribution. If you installed a 6.x Windows beta, the README says to install the 7.0.0 Setup EXE once to move to the new updater; from 7.0.0 onward, Windows installations receive automatic updates from GitHub Releases. ## A first real use: split terminals, then find an old session The first thing worth doing after launch is getting the terminal layout right, because that is the interaction the rest of the app assumes. The README states that Ghostex uses the same configurable hotkey flow as terminals like Ghostty and cmux: Cmd/Ctrl + T opens a new terminal, Cmd/Ctrl + D splits, and shortcuts move between panes. Launch your agent CLI of choice inside one pane, for example by running the agent command in the terminal rather than through any Ghostex-specific wrapper. The README does not document a launcher flag for a specific agent, so the terminal is the entry point. The second feature to try is session search, which is where the multi-agent premise pays off. The README says you can fuzzy search previous sessions across all agents by typing a few words from your prompts, press enter to resume, and start it from the sidebar or from the CLI. ```bash ghostex find gx f ``` The README gives both spellings, so gx is a short alias for the ghostex binary. Expect a list of past sessions from every agent CLI Ghostex has seen, filterable by title, tag or last active. If a session you know exists does not appear, the likely cause is that it was created outside Ghostex and never registered with the daemon; the README does not describe an import path for pre-existing agent history. For remote work, the pattern is to install gxserver on the host and connect a client to it. The README states the daemon can be installed on any remote machine, but it does not give a gxserver install command or a connection configuration example, so the exact invocation is something you will have to find in the repository's docs directory or the Discord rather than in the README. ## Where Ghostex is the wrong tool The Windows limitation is the most concrete one, and it is stated rather than implied. A beta that only supports WSL2 workflows is not a substitute for a native Windows terminal, and the README says so directly. If your team develops on Windows without WSL2, this is not your tool yet. The host support list is the second boundary. Clients include Android and a TUI, but supported hosts are macOS and Linux, tested on Ubuntu x64 and arm64. A remote host running anything else is outside what the README claims. The dependency on a downloaded Chromium runtime is a third constraint that cuts against the low-RAM pitch. Ghostex advertises low-RAM Ghostty terminals and a native Rust/GPUI interface, which is a real architectural difference from Electron-based terminals. But the embedded browser panes use Chromium CEF, and the README says the browser runtime is not bundled and is fetched on first GUI launch. The memory profile of a session with several browser panes open will not resemble the memory profile of a session with terminals only. The README does not publish figures for either case. Finally, there is no documented rollback. The README describes automatic updates from GitHub Releases for Windows and a Homebrew cask for macOS, but no downgrade procedure and no version pinning guidance. If you need reproducible tool versions across a team, that gap matters more than any feature on the list. ## Ghostex compared with tmux plus a terminal emulator The honest alternative is tmux inside whatever terminal you already use. tmux gives you splits, persistent sessions, and remote attachment through SSH, and it has been stable for years. The difference in approach is where session state lives and what the UI knows about it. With tmux, the session is a set of panes running shells. tmux has no concept of an agent, so it cannot list your previous Claude Code sessions by title, cannot show a menu bar indicator for a running agent, and cannot render the same session as a chat GUI. Ghostex puts a daemon between the client and the process specifically so those things become possible. The README's session search, notification sounds, menu bar indicators and phone notifications all depend on that layer existing. The cost is a heavier stack. tmux needs a shell and a terminal. Ghostex needs a GPUI desktop app, a gxserver daemon, zmx for persistence and a downloaded Chromium runtime for browser panes. If your actual problem is "keep three shells alive on a server", tmux solves it with less surface area. If your problem is "I have four agents running and I cannot remember what I asked any of them", the daemon layer is doing work tmux cannot do. A second comparison worth noting is against plain terminal emulators with split panes. Those give you the layout without the session registry. Ghostex's split hotkeys are described as matching that familiar flow, which suggests the layout itself is not the differentiator; the registry and the remote clients are. ## Licence, maintenance and upgrade cost Ghostex is MIT licensed. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are preserved. It also means the project offers no warranty, which is worth weighing against the beta status of the Windows path and the absence of a documented downgrade route. Nothing here is legal advice, and the LICENSE file in the repository is the authoritative text. The repository is not archived and the last push was on 2026-08-28, the same day as the v8.2.0 release. Three releases landed in the four days before that: v8.1.0 on 2026-08-27 and v8.0.0 on 2026-08-25. That cadence is fast, and fast cadences have a cost for adopters. The repository's package.json lists a long set of release scripts, including resumable release steps and a preflight check, which suggests the maintainers have felt that cost themselves. Note also that package.json reports version 9.5.1 while the most recent GitHub release listed is v8.2.0; the two numbering tracks do not match, so do not assume a package version implies a release version. The README states the project is looking for contributors and points to a Discord. A project actively recruiting help in its own README is telling you something about its current capacity. For an adopter, the practical implication is that the upgrade path is automatic on Windows and cask-based on macOS, and neither is described as reversible. ## Conclusion Adopt Ghostex if you already keep several agent CLIs open and want them in one window with a searchable session history and a phone client. Do not adopt it if you need a stable Windows-native terminal, since the README labels that path a WSL2-only beta, or if your workflow depends on tmux scripting you cannot replace. Before committing, verify two things: that the Homebrew cask `maddada/tap/ghostex` resolves on your machine, and that a `gxserver` daemon on your target host is reachable from the client you intend to use. The README documents neither a rollback path for a failed upgrade nor a supported downgrade procedure, so treat the first install as the point of no easy return. ## FAQ ### How do I install Ghostex on macOS? The README gives a Homebrew cask that installs the Apple Silicon build: brew trust maddada/tap then brew install --cask maddada/tap/ghostex. A macOS Apple Silicon DMG is also offered as a direct download. ### Does Ghostex work on Windows? There is a Windows app, but the README labels it a beta intended for WSL2 workflows only that may still have bugs, and states that native Windows shell workflows are not the intended setup. Ghostex manages its terminals, gxserver and Source editor inside the selected WSL2 distribution. ### What is gxserver in Ghostex? gxserver is the daemon in the client/server split described as client apps, gxserver daemon and zmx persistence. The README says installing just the gxserver daemon on a remote machine lets you control the agents on that machine from any client device. ## Sources - [Official documentation](https://ghostex.dev) - [Official README](https://github.com/maddada/Ghostex#readme) - [Project repository](https://github.com/maddada/Ghostex) - [Release notes](https://github.com/maddada/Ghostex/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/maddada-ghostex