OpenSessions for tmux
A tmux sidebar for monitoring, organizing, and jumping between live coding-agent sessions.
Per-dimension scores and reasoning
Evidence shows: local HTTP API defaults to 127.0.0.1, ports derived per tmux socket, but no authentication or authorization mentioned; install script downloads prebuilt binaries without checksum verification; auto-version workflow exists but no user confirmation mechanism. Deductions: lack of user confirmation, limited data flow transparency, insufficient sensitive data handling details, dependency security not fully verified.
Evidence shows: README and code structure consistent, documentation describes multiple components and integrations; but external dependencies (e.g., lazydiff's Convex URL) may affect availability; failure messages not detailed. Deductions: dependency availability not fully guaranteed, failure messages unclear.
Evidence shows: targets developers using tmux, supports multiple agents, provides configuration and API; capability boundaries described in README (e.g., only tmux supported); triggers clear (keybindings); environment fit good (Linux/macOS). Deductions: capability boundaries not exhaustive, environment fit not all platforms.
Evidence shows: clear documentation structure, detailed install notes, stable naming (e.g., opensessions-sidebar), examples and FAQ provided, known limitations explicit, MIT license, version number exists but no changelog, maintenance responsibility unclear. Deductions: missing changelog, maintenance responsibility unclear.
Evidence shows: high output usability (API and UI), clear marginal value (solves multi-session management), reasonable cost-benefit (Rust, zero runtime dependencies). Deductions: none significant.
Evidence shows: README claims mostly consistent with code structure, but lack independent verification; cross-source corroboration insufficient; facts and inferences not clearly separated. Deductions: limited claim traceability, insufficient cross-source corroboration, facts and inferences not clearly separated.
- Local HTTP API has no authentication mentioned, potentially allowing other processes on the same host to modify state.
- Install script downloads prebuilt binaries without checksum verification, posing supply chain risk.
- Auto-version workflow may modify package.json and push tags without user confirmation.
What does this agent do, and when should you use it?
OpenSessions is a Rust sidebar that stays inside an existing tmux workflow while terminal sessions, coding agents, and localhost tabs multiply. Its implementation includes a ratatui sidebar client, a Rust state server, shared runtime packages, and tmux integration scripts; the client connects to the server over WebSocket. The server combines tmux state with local records from Amp, Claude Code, Codex, and OpenCode, exposing branches, working directories, thread names, and detected localhost ports in the UI. Users can switch, reorder, hide, restore, create, and kill sessions, while scripts and agents can post status, progress, and logs to a local HTTP API. It is a local-only application by default, binding to 127.0.0.1; tmux is the only currently supported multiplexer.
The runtime reads tmux sessions plus ~/.local/share/amp/threads/*.json, JSONL transcripts under ~/.claude/projects/, JSONL transcripts under ~/.codex/sessions/ or $CODEX_HOME/sessions/, and ~/.local/share/opencode/opencode.db. It resolves Codex sessions from turn_context.cwd, can clear Amp unseen state through Amp's session.json, assembles live state, and serves it to opensessions-sidebar over WebSocket. The sidebar renders agent status and per-thread unseen markers for done, error, and interrupted states; when it detects a port, it can open http://localhost:<port>. Scripts or agents can POST session metadata to 127.0.0.1:7391/set-status, /set-progress, /log, /clear-log, or /notify to produce status pills, progress, logs, and notifications.
- A developer running Claude Code, Codex, or Amp across several repositories in tmux can inspect live session state and jump to the right terminal from one sidebar.
- An engineer with several local development servers in tmux can use detected localhost ports to open the relevant service quickly.
- A team whose CI or deployment scripts need terminal-visible feedback can post deployment state, test progress, and logs through the local HTTP API.
- A solo developer handling multiple agent threads can use unseen done, error, and interrupted markers to find work that needs attention.
- A tmux user who wants persistent session ordering, hide/restore behavior, and keyboard switching without adopting a different multiplexer can use the sidebar controls.
What are this agent's strengths and limitations?
- It augments an existing tmux workflow instead of replacing the multiplexer.
- It aggregates local session state for Amp, Claude Code, Codex, and OpenCode, using the concrete records documented for each source.
- Its local HTTP endpoints let scripts publish status, progress, and logs without requiring a separate client binary.
- The native Rust ratatui client receives server state over WebSocket and is described as having zero runtime dependencies.
- tmux is the only documented supported multiplexer; older zellij integration is explicitly described as unstable.
- Adoption requires local tmux and TPM, plus curl or wget for the normal first-load binary download; unsupported platforms may require a Cargo build.
- Agent monitoring depends on local, provider-specific data locations and formats, including Claude Code and Codex JSONL transcripts and the OpenCode SQLite database.
- The documented default is local-only on 127.0.0.1, and parsed plugins, port, and keybinding settings are not active runtime extension hooks today.
How do you install or deploy this agent?
Requirements: tmux, TPM, and curl or wget to download prebuilt binaries on first load. Add this to ~/.tmux.conf:
set -g @plugin 'Ataraxy-Labs/opensessions'Then run:
tmux source-file ~/.tmux.conf
~/.tmux/plugins/tpm/bin/install_pluginsOn first load, the plugin downloads a release bundle containing opensessions-sidebar, opensessions-server, and lazydiff. Open the sidebar with prefix o → s. For an unsupported platform or local development:
cd ~/.tmux/plugins/opensessions
cargo build --releaseHow do you use this agent?
Within tmux, use prefix o → s to focus the sidebar and prefix o → t to toggle it; prefix o → 1 through 9 switches sessions quickly. To set a status from a script, run:
curl -X POST http://127.0.0.1:7391/set-status -H 'content-type: application/json' -d '{"session":"my-app","text":"Deploying","tone":"warn"}'For local development, start the sidebar with cargo run -p opensessions-sidebar or the server with cargo run -p opensessions-server.