anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 02:36:57 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Feature Request: Add tmux Support for Multi-Session Agent Testing #879

New Issue
Open
opened 2026-02-16 17:28:39 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:28:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @sandipwane on GitHub (Jul 23, 2025).

Originally assigned to: @thdxr on GitHub.

⚠️ Note: I understand from the contribution guidelines that core features need to go through a design process with the core team. I'm opening this issue to start that discussion and gauge interest, not planning to submit a PR without approval.

Summary

Enable OpenCode to manage multiple persistent terminal sessions through tmux integration, allowing it to handle complex workflows with parallel processes, persistent environments, and interactive CLI testing.

Current Limitations

  • No persistence: Can't keep servers running while coding
  • No parallelism: Can't run tests while dev server is active
  • No interactive testing: Can't test CLIs that require user input
  • No real-time monitoring: Can't observe and react to process output

Proposed Solution

Integrate tmux to enable:

  • Multiple persistent terminal sessions
  • Parallel process execution
  • Send keystrokes/input to sessions (crucial for CLI testing)
  • Real-time output monitoring
  • Session switching and management

Key Benefits

1. Interactive CLI Testing

# OpenCode can now test CLIs that require user input\!
Session 1: npm init
  → Send: "my-app" (project name)
  → Send: "1.0.0" (version)
  → Send: "yes" (confirm)

2. Full-Stack Development

Run entire stack in parallel:

  • Frontend: npm run dev
  • Backend: node server.js
  • Database: redis-server
  • Tests: npm test --watch

3. Real-World Example

Current: "I can't fully test this auth flow because I'd need Redis running..."

With tmux: OpenCode starts Redis, runs the app, tests auth flow, monitors sessions, and confirms: "Auth flow tested successfully with proper session storage."

Implementation

Tmux provides a clean API for this functionality:

  • Create/manage named sessions
  • Send keystrokes to sessions (tmux send-keys)
  • Capture output from sessions (tmux capture-pane)
  • Check session status and health

This would be backwards compatible - OpenCode would detect tmux availability and fall back to current behavior if not present.

Why This Matters

  • GitHub Copilot/Cursor/Aider: None support multiple persistent sessions
  • Real Development: Developers always have multiple terminals open
  • Complex Testing: Many tools require interactive input
  • Better AI Assistance: OpenCode could actually verify its work

Conclusion

This single feature would make OpenCode the only AI assistant capable of truly testing and verifying complex applications, especially those with interactive CLIs or multiple services. It bridges the gap between "code generation" and "working software".

Originally created by @sandipwane on GitHub (Jul 23, 2025). Originally assigned to: @thdxr on GitHub. ⚠️ **Note**: I understand from the contribution guidelines that core features need to go through a design process with the core team. I'm opening this issue to start that discussion and gauge interest, not planning to submit a PR without approval. ## Summary Enable OpenCode to manage multiple persistent terminal sessions through tmux integration, allowing it to handle complex workflows with parallel processes, persistent environments, and **interactive CLI testing**. ## Current Limitations - **No persistence**: Can't keep servers running while coding - **No parallelism**: Can't run tests while dev server is active - **No interactive testing**: Can't test CLIs that require user input - **No real-time monitoring**: Can't observe and react to process output ## Proposed Solution Integrate tmux to enable: - Multiple persistent terminal sessions - Parallel process execution - **Send keystrokes/input to sessions** (crucial for CLI testing) - Real-time output monitoring - Session switching and management ## Key Benefits ### 1. Interactive CLI Testing ```bash # OpenCode can now test CLIs that require user input\! Session 1: npm init → Send: "my-app" (project name) → Send: "1.0.0" (version) → Send: "yes" (confirm) ``` ### 2. Full-Stack Development Run entire stack in parallel: - Frontend: `npm run dev` - Backend: `node server.js` - Database: `redis-server` - Tests: `npm test --watch` ### 3. Real-World Example **Current**: "I can't fully test this auth flow because I'd need Redis running..." **With tmux**: OpenCode starts Redis, runs the app, tests auth flow, monitors sessions, and confirms: "Auth flow tested successfully with proper session storage." ## Implementation Tmux provides a clean API for this functionality: - Create/manage named sessions - Send keystrokes to sessions (`tmux send-keys`) - Capture output from sessions (`tmux capture-pane`) - Check session status and health This would be backwards compatible - OpenCode would detect tmux availability and fall back to current behavior if not present. ## Why This Matters - **GitHub Copilot/Cursor/Aider**: None support multiple persistent sessions - **Real Development**: Developers always have multiple terminals open - **Complex Testing**: Many tools require interactive input - **Better AI Assistance**: OpenCode could actually verify its work ## Conclusion This single feature would make OpenCode the only AI assistant capable of truly testing and verifying complex applications, especially those with interactive CLIs or multiple services. It bridges the gap between "code generation" and "working software".
yindo commented 2026-02-16 17:28:39 -05:00
Author
Owner
Copy Link
Copy Source

@nitsanavni commented on GitHub (Jul 24, 2025):

I use this workflow a lot. Helpful in many situations. Great tool to have.
I use this custom slash command:

execute commands in a dedicated tmux window

# context - when to use?

we want to manually test or execute an interactive cli
or a long interaction with a remote terminal (e.g. via ssh)
or just a long running process, that we'll want to check in with later

# how

if already in a tmux session - create a new properly named window
if not in a tmux session - create one
use `send-keys` to write to it and `capture-pane` to read from it
always start with read
then also make sure we're in the expected pwd
in general - read more often then write

# tips

some interactive clis require a bit of pause from time to time - e.g. Claude Code, when sending a msg to claude use bash(send(msg), sleep 0.1, send(Enter))
@nitsanavni commented on GitHub (Jul 24, 2025): I use this workflow a lot. Helpful in many situations. Great tool to have. I use this custom slash command: ```md execute commands in a dedicated tmux window # context - when to use? we want to manually test or execute an interactive cli or a long interaction with a remote terminal (e.g. via ssh) or just a long running process, that we'll want to check in with later # how if already in a tmux session - create a new properly named window if not in a tmux session - create one use `send-keys` to write to it and `capture-pane` to read from it always start with read then also make sure we're in the expected pwd in general - read more often then write # tips some interactive clis require a bit of pause from time to time - e.g. Claude Code, when sending a msg to claude use bash(send(msg), sleep 0.1, send(Enter)) ```
yindo commented 2026-02-16 17:28:39 -05:00
Author
Owner
Copy Link
Copy Source

@lee-b commented on GitHub (Jul 26, 2025):

Additional potential use case: logging into various servers/containers/jails, for distributed systems/solutions. This is potentially very useful for using opencode to work on IaC, for example.

@lee-b commented on GitHub (Jul 26, 2025): Additional potential use case: logging into various servers/containers/jails, for distributed systems/solutions. This is potentially very useful for using opencode to work on IaC, for example.
yindo commented 2026-02-16 17:28:39 -05:00
Author
Owner
Copy Link
Copy Source

@abda11ah commented on GitHub (Dec 24, 2025):

Openhands handles it but it is running in docker isolated envirronment which adds a complexity layer for simple setups

@abda11ah commented on GitHub (Dec 24, 2025): Openhands handles it but it is running in docker isolated envirronment which adds a complexity layer for simple setups
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#879
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?