Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [FEATURE] Single-agent, multi-terminal sessions (daemon + client workflows)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Claude Code today supports multi-pane terminals via Agent Teams (teammateMode: "tmux" / iTerm2 split panes), but Agent Teams is designed for multiple agents — one teammate per pane. This request is for the complementary case: a single Claude agent that owns multiple terminals so it can run a persistent daemon in one and drive it from another, without spawning sub-agents or losing live output.

Error Message

  • Optionally: Claude can watch output from a background terminal and react when something meaningful happens (test fails, server logs an error).

Root Cause

Agent Teams can't currently be repurposed for this because each pane runs its own Claude instance with its own context.

RAW_BUFFERClick to expand / collapse

Summary

Claude Code today supports multi-pane terminals via Agent Teams (teammateMode: "tmux" / iTerm2 split panes), but Agent Teams is designed for multiple agents — one teammate per pane. This request is for the complementary case: a single Claude agent that owns multiple terminals so it can run a persistent daemon in one and drive it from another, without spawning sub-agents or losing live output.

User context

I recently switched to the Claude Desktop app after running Claude Code inside the VS Code integrated terminal. One of the things I immediately missed is the ability to have multiple terminals open in the same working context — something VS Code supports by default and which made daemon + client workflows effortless. Reproducing that inside Claude Desktop would remove one of the biggest friction points of the migration.

Motivating workflows

  • Daemon + client. Run a dev server, API, database, or WebSocket daemon in one terminal and hit it with curl, a test client, or a REPL in another. Today the options are: background the server and lose live logs, or step outside Claude Code entirely.
  • Log tailing alongside active work. tail -f, docker logs -f, or kubectl logs -f in one pane while running commands in another.
  • Watchers and builders. npm run dev, vite, webpack --watch, cargo watch, or pytest --watch running continuously while one-off commands execute elsewhere.
  • Multi-service local stacks. Frontend + backend + worker, each needing its own terminal for live output.
  • Debugger + target process. gdb / lldb / language-specific debuggers in one terminal, program under test in another.
  • Git ops during long-running tasks. git status / diffs / commits while a build or test suite runs.

How this differs from Agent Teams

Agent TeamsThis request
One agent per pane (teammates)One agent, many panes
Panes coordinate as collaboratorsPanes are tools the agent uses
Optimized for parallel agent workOptimized for daemon/client-style workflows within a single task

Agent Teams can't currently be repurposed for this because each pane runs its own Claude instance with its own context.

Proposed behavior

  • Allow a single session to open multiple named terminals (tabs, panes, or a terminal list).
  • Claude addresses terminals by name/ID: send input to a specific terminal, read output from any of them.
  • Long-running processes (servers, watchers) persist in their own terminal while Claude continues working in others.
  • Ideally reuses the existing pane-backend abstraction (tmux, iTerm2, and the in-flight zellij / WezTerm / Windows Terminal backends) that Agent Teams already uses.
  • Optionally: Claude can watch output from a background terminal and react when something meaningful happens (test fails, server logs an error).

Why it matters

Most non-trivial development is not a single linear command stream — it is a server plus clients, a build plus tests, a watcher plus edits. A single terminal forces Claude to stop and restart processes, or hand control back to the user mid-task. Adding single-agent multi-terminal support — on top of the pane infrastructure that already exists — would unlock a large class of real-world workflows without the overhead of spawning multiple agents.

Related

  • teammateMode: "tmux" / Agent Teams (existing, complementary feature)
  • Active pane-backend work: zellij, WezTerm, Windows Terminal issues

extent analysis

TL;DR

To support single-agent multi-terminal workflows, Claude Code should extend its existing pane-backend abstraction to allow a single session to open multiple named terminals.

Guidance

  • Review the proposed behavior section to understand the desired functionality, including opening multiple named terminals, addressing terminals by name/ID, and persisting long-running processes.
  • Investigate reusing the existing pane-backend abstraction (tmux, iTerm2, and in-flight backends) that Agent Teams already uses to minimize development effort.
  • Consider the differences between Agent Teams and the requested feature, as outlined in the comparison table, to ensure the new implementation meets the specific requirements of single-agent multi-terminal workflows.
  • Evaluate the potential benefits of watching output from background terminals and reacting to meaningful events, such as test failures or server errors.

Example

No code snippet is provided, as the issue focuses on high-level functionality and design rather than specific implementation details.

Notes

The implementation of single-agent multi-terminal support will require careful consideration of the existing Agent Teams feature and the pane-backend abstraction. It is essential to ensure that the new functionality integrates seamlessly with the existing infrastructure and does not introduce unnecessary complexity or overhead.

Recommendation

Apply a workaround by utilizing the existing Agent Teams feature with a single agent per pane, although this may not provide the exact functionality desired, it can help mitigate some of the current limitations until a more comprehensive solution is implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#latency issue#model loading#dependency error#configuration error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [FEATURE] Single-agent, multi-terminal sessions (daemon + client workflows)