Summary
Arbor currently has two frontends: the GPUI native desktop app (arbor-gui) and the web UI (arbor-web-ui). Both require either a desktop environment or a browser. For users who work primarily in the terminal (tmux-based workflows, SSH sessions, headless servers), a ratatui-based TUI would be a valuable third frontend.
Proposal
Add a new arbor-tui crate to the workspace — a terminal dashboard that talks to the arbor-httpd daemon over its existing HTTP + WebSocket API (via arbor-daemon-client).
Key views
- Agent activity — live working/waiting status for Claude Code, Codex, Pi, OpenCode sessions (via
/api/v1/agent/activity/ws)
- Repositories — tracked repos with worktree status
- Terminals — list daemon-managed terminal sessions with live snapshots (via
/api/v1/terminals/{id}/snapshot)
- Processes — managed process status
Architecture
arbor-tui
├── depends on: arbor-daemon-client (typed HTTP client)
├── uses: ratatui + crossterm
├── talks to: arbor-httpd daemon (same as arbor-cli and arbor-gui)
└── binary: arbor-tui (or `arbor-cli tui` subcommand)
No GPUI dependency. Builds on any platform with a terminal.
Why ratatui
- De facto standard for Rust TUIs (same ecosystem as Zed's terminal work)
- Active community, well-documented
- Pairs naturally with crossterm for cross-platform terminal handling
- Used by OpenViking's CLI, gitui, lazygit-rs, and many others
Use case
I manage multiple Claude Code sessions in tmux across several projects. The web UI is great for monitoring from a browser, but when I'm already in a terminal session, switching to a browser breaks flow. A TUI that I can open in a tmux pane alongside my agents would be ideal.
Willingness to contribute
I'm happy to implement this. Would like to understand if this aligns with the project's direction before forking — would you accept a PR for this, or would you prefer it lives as a separate project?
Summary
Arbor currently has two frontends: the GPUI native desktop app (
arbor-gui) and the web UI (arbor-web-ui). Both require either a desktop environment or a browser. For users who work primarily in the terminal (tmux-based workflows, SSH sessions, headless servers), a ratatui-based TUI would be a valuable third frontend.Proposal
Add a new
arbor-tuicrate to the workspace — a terminal dashboard that talks to thearbor-httpddaemon over its existing HTTP + WebSocket API (viaarbor-daemon-client).Key views
/api/v1/agent/activity/ws)/api/v1/terminals/{id}/snapshot)Architecture
No GPUI dependency. Builds on any platform with a terminal.
Why ratatui
Use case
I manage multiple Claude Code sessions in tmux across several projects. The web UI is great for monitoring from a browser, but when I'm already in a terminal session, switching to a browser breaks flow. A TUI that I can open in a tmux pane alongside my agents would be ideal.
Willingness to contribute
I'm happy to implement this. Would like to understand if this aligns with the project's direction before forking — would you accept a PR for this, or would you prefer it lives as a separate project?