# CC-Panes, a split-pane desktop for running several AI coding agents > CC-Panes is a Tauri 2 desktop application that runs CLI coding agents side by side in real PTY panes, and wraps them with launch profiles, Git worktree tooling, planning surfaces and an MCP server that lets one agent dispatch workers. It is a local tool, not a hosted service. **wuxiran/cc-pane** — Multi-instance split-pane manager for Claude Code — a cross-platform desktop app built with Tauri 2 - Repository: https://github.com/wuxiran/cc-pane - Stars: 568 · Forks: 59 - Language: TypeScript - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/wuxiran-cc-pane ## A window for many agent sessions instead of many windows CC-Panes describes itself as the desktop command center for parallel AI coding. Run CLI agents side by side, organize their workspaces and sessions, then coordinate the work through MCP, plans, skills, Git and local history. The problem it addresses is concrete and familiar to anyone who has tried to run more than one coding agent at once. Terminal multiplexers give you panes, but they give you panes of shells, not panes of sessions that know which project they belong to, what plan they are following, and what they produced. You end up with a tmux session per project, a notes file somewhere else, and a set of git worktrees you have to remember. CC-Panes puts that back together in one local desktop view. The workspace command center shows active sessions, recent projects, available CLIs, usage trends and workspace context, and the README says you can move between a workspace, project, task and terminal without losing the thread of the work. The terminal layer underneath is a real one. The feature list describes real PTY sessions with flexible horizontal and vertical layouts, scrollback, and saved pane layouts in one window. That matters more than it sounds: an agent CLI that needs a real terminal, with a real shell, will not run inside a fake terminal emulation, and the difference shows up in how interactive prompts, colour output and terminal control sequences behave. The application is built with Tauri 2 and TypeScript, and it ships for Windows, macOS and Linux. The license is GPL-3.0. The last push to the repository was on 2026-10-19, and the recorded releases are v0.12.21 from 2026-10-12, v0.12.20 from 2026-09-16 and v0.12.19 from 2026-09-15. The audience is a developer who already uses CLI coding agents daily and has hit the ceiling of managing them in separate terminal windows. ## Launch profiles turn a CLI invocation into a reusable configuration The launch profile is the feature that makes CC-Panes more than a terminal multiplexer, and it is worth understanding what it holds. A profile bundles a CLI, a provider, an MCP set, skills, a runtime and a permission policy into one reusable unit. The point is that starting an agent with the right provider, the right tools and the right permissions should not be a retyped command line every time. The runtime slot is what gives the profile its range. The README says local, WSL and SSH workflows sit under the same workspace model, so the same project can be driven from a local shell, from a distribution's WSL environment, or over SSH to a remote host, and the pane arrangement and project structure stay the same across all three. That is the part that is hard to do by hand: today the difference between a local session and a remote one is not just where the shell runs but which tools, environment and project layout you get, and a profile makes that explicit. Permission policy sits in the same bundle, which is a deliberate choice. An agent that can run commands needs a permission boundary, and making the boundary part of the profile means the boundary travels with the launch rather than being whatever the CLI happens to default to. The skills and shared tooling area extends the same idea to reusable workflows. You can browse reusable workflows, manage global skills, and attach shared MCP services to the profiles that need them. The README makes a point of not forcing skills into every session, which is the right default, since a large skill list in every session is context you pay for on every request. Together, profiles and skills are the difference between a pane manager and a launcher. A pane manager runs whatever command you type. This runs a named configuration, and it knows where the workspace, the plan and the history are. ## The ccpanes MCP server lets one agent dispatch others The orchestration feature is the most ambitious part of the project, and it is built on MCP rather than on a proprietary protocol. The built-in `ccpanes` MCP lets a leader dispatch workers, observe their progress, collect results, and keep plans and Todos close to the sessions that perform the work. In other words, the leader is another coding agent running in a pane, and the MCP server is the mechanism it uses to talk to the sessions CC-Panes manages. That choice of mechanism is what makes it composable. MCP is a protocol the agent already speaks, so the leader does not need a special mode or a special model to be able to use it. Any CLI that supports MCP servers can act as the leader. The planning surfaces are the other half. Todos, journals, plans, specs, session summaries and persistent memory stay next to the agents doing the work. This is the piece that answers the failure mode of parallel agent work, where two agents finish and nobody can reconstruct what either of them decided or why a particular edit was made. The persistent memory component is a separate crate in the repository tree, `cc-memory/`, alongside `cc-memory-mcp/` and `cc-notify/`, and there is a dedicated guide in `docs/guide/09-todo-journal-memory.md`. The split into separate Rust crates is visible throughout the tree, and it is worth noting because it tells you what the maintainers consider separable concerns. The repository also carries `cc-cli-adapters/`, which is the layer that lets the app drive different CLI agents, and `cc-panes-api/`, `cc-panes-core/`, `cc-panes-daemon/`, `cc-panes-ctl/` and `cc-panes-cli-hook/`. A daemon plus a control client plus a core library is a fairly conventional split for something that has to keep sessions alive independently of any one window, and it is also what makes the remote access feature possible. ## A Rust workspace with a TypeScript front end The architecture is visible in the build files, and it is a substantial codebase for a 0.x release. The Cargo workspace lists eleven members: `src-tauri`, `cc-panes-core`, `cc-panes-api`, `cc-panes-daemon`, `cc-panes-cli-hook`, `cc-panes-ctl`, `cc-panes-web`, `cc-memory`, `cc-memory-mcp`, `cc-notify` and `cc-cli-adapters`. So the Rust side is not just the Tauri shell, it is the majority of the application logic, and the front end is the Vite and TypeScript layer on top. The workspace uses resolver version 2, and the Cargo profile settings carry a comment that is worth reading as an engineering note. The dev profile sets `debug = 1` for the project's own code and `debug = 0` for all dependencies, and the comment explains why in plain terms: the default of 2 would generate full debug information for all 914 dependencies, which is the main cause of the debug build directory swelling to over a hundred gigabytes, and the linker has to read and merge that information on every relink. The release profile keeps line tables for the project's own binaries while stripping dependency debug info, with a note to retain matching PDB files with future builds. That is a specific, dated engineering decision about build performance, and it tells you something about how the project is maintained. The front end scripts are ordinary Vite and Vitest commands, with a few that show the project's priorities. ```json "dev": "vite", "build": "vite build && node scripts/verify-xterm-build.mjs", "check:theme-contrast": "node scripts/check-theme-contrast.mjs", "check:bundle": "node scripts/check-bundle-size.mjs", "test": "vitest", "tauri:dev": "tauri dev --config src-tauri/tauri.dev.conf.json", ``` The build script runs a verification step for the xterm build after bundling, which is the terminal emulation the PTY panes rely on, so a broken xterm artefact fails the build rather than producing a blank terminal at runtime. The theme contrast check and the bundle size check are both run as separate scripts, and there are separate performance summary and comparison scripts with their own tests, plus a smoke test for the static terminal replay and one for the daemon and web combination. The documentation site is VitePress, with dev, build and preview scripts, and the docs directory also holds the per-feature guides that the README links to from each feature card. ## Running the web and daemon build in a container Not every part of CC-Panes is a desktop app. The workspace includes `cc-panes-web`, and the repository ships a Dockerfile and a compose file for it, which is the way to reach the same workspace from a browser. The image is a two-stage build on Rust. ```dockerfile FROM rust:1.82-bookworm AS builder WORKDIR /app COPY . . RUN cargo build --release -p cc-panes-web ``` The runtime stage is a Debian bookworm slim image that installs ca-certificates and procps, copies the built binary to `/usr/local/bin/`, exposes port 8080, sets `CC_PANES_CWD=/workspace`, and starts the binary with the port and working directory arguments. ```bash ENTRYPOINT ["cc-panes-web"] CMD ["--port", "8080", "--cwd", "/workspace"] ``` The compose file ties that to a port mapping and a workspace mount. ```yaml services: cc-panes-web: build: . ports: - "8080:8080" volumes: - ./:/workspace environment: - RUST_LOG=cc_panes_web=info,cc_panes_core=info ``` The `CC_PANES_CWD` variable and the `--cwd` flag are the important detail here. They tell the server which directory is the workspace it is managing, and the compose file mounts the current directory there. That is the whole remote-access model in one line: the container has to be given the directory it is supposed to act on, and it has no other idea what that directory is. The `RUST_LOG` value limits logging to the web and core crates at info level, which is the standard Rust tracing filter syntax and a reasonable default for a service that will be attached to a lot of agent activity. Two caveats about this route. The Dockerfile copies the entire repository into the builder stage, so the build context is the whole tree including the web front end, which is fine for a local build and slow for a CI cache. And the web binary manages the workspace it is given, so running it against a directory you care about is worth doing on a scratch copy first. ## Where the boundaries are Three limits are worth stating before someone adopts this. The first is that it drives CLI agents rather than embedding models. The launch profile chooses a CLI and a provider, and the app's job is to run the CLI in a pane with the right environment. That means every capability the CLI has, it has, and every limitation it has, it has. It also means the app cannot do anything the CLI cannot, which is a real boundary on the orchestration story: a leader that wants to dispatch workers is relying on MCP support in the CLI it is running as leader. The second is that the file surface is broad. There is a file browser, a Monaco editor, Markdown and image previews, project hooks and CLI adapters in the same shell. That is a lot of surface for an application whose main job is hosting terminals, and the parts you do not use still have to behave correctly on your platform. The third is the licence and the release cadence together. The project is GPL-3.0, which for a desktop application that most people install rather than redistribute is a low-impact constraint, but it matters if you intend to fork the code into something you ship. The version is 0.12.21, which is still a pre-1.0 line, and the releases are frequent, v0.12.19, v0.12.20 and v0.12.21 within a month. Frequent releases at 0.x mean the internal APIs move, and the README's own guidance to consult the per-feature guides in `docs/guide/` rather than assume the UI is stable is the practical advice to follow. The alternative to CC-Panes is not another pane manager, it is a terminal multiplexer with some discipline. tmux or Zellij gives you panes and persistence with far less machinery, and for two or three agents that is often enough. What CC-Panes adds over that is the project model, the profiles, the plans and the agent-to-agent orchestration. If you are running agents in one project at a time and mostly watching them, the multiplexer is the cheaper answer. If you are running many, across projects, and want the history to be attached to the work rather than to a scrollback buffer, the extra machinery earns its place. ## Conclusion CC-Panes suits a developer who already drives coding agents from the terminal and wants several of them running in one window with a shared notion of projects, plans and history, and it suits a team standardising on a particular CLI, provider and MCP set through launch profiles. It does not suit someone looking for a managed agent service, since the whole design is local. Verify first that the CLI you want to drive is one of the supported adapters, that the MCP permissions your profile grants are acceptable, and that the GPL-3.0 licence fits a project you intend to modify and redistribute. ## FAQ ### What is CC-Panes? It is a cross-platform desktop application built with Tauri 2 and TypeScript that runs CLI coding agents side by side in real PTY panes, and adds launch profiles, Git worktree tooling, planning surfaces and a built-in MCP server for agent orchestration. It ships for Windows, macOS and Linux. ### What does a launch profile contain in CC-Panes? A CLI, a provider, an MCP set, skills, a runtime and a permission policy, bundled as one reusable unit. The runtime slot covers local, WSL and SSH workflows under the same workspace model, and the permission policy travels with the launch. ### How does CC-Panes let one agent dispatch other agents? Through the built-in ccpanes MCP server, which lets a leader dispatch workers, observe their progress, collect results, and keep plans and Todos close to the sessions doing the work. Because it is MCP, any CLI that supports MCP servers can act as the leader. ### Can I run CC-Panes on a remote machine? The repository includes a cc-panes-web crate with a Dockerfile and a compose file. The image exposes port 8080, sets CC_PANES_CWD=/workspace, and starts the binary with --port 8080 --cwd /workspace, so the server needs to be told which directory it should manage. ### What licence is CC-Panes released under? GPL-3.0, with the LICENSE file at the root of the repository and the package manifest declaring the same. The current version is 0.12.21 and the last push to the repository was on 2026-10-19. ## Sources - [Issues](https://github.com/wuxiran/cc-pane/issues) - [License: GPL-3.0](https://github.com/wuxiran/cc-pane/blob/main/LICENSE) - [README](https://github.com/wuxiran/cc-pane/blob/main/README.md) - [Releases](https://github.com/wuxiran/cc-pane/releases) - [wuxiran/cc-pane on GitHub](https://github.com/wuxiran/cc-pane) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wuxiran-cc-pane