Terminal spawns new VS Code terminals instead of reusing existing one

[hannesrudolph]

Description

Terminal functionality is spawning new VS Code terminals instead of reusing an existing one. This leads to many “Roo Code” terminals accumulating during normal usage.

🔁 Steps to Reproduce

1. Run a command via the extension (execute_command) from a project directory.
2. After it finishes, run another command from the same project directory/task.
3. Observe that a new VS Code terminal is created instead of reusing the previous one.

Variants that also reproduce:

• First command changes directory in-terminal (e.g., cd src). A subsequent command requested for the original cwd may fail the reuse check and create a new terminal.
• If shell integration falls back and later recovers, provider mismatch (“vscode” vs “execa”) can prevent reuse.

💥 Outcome Summary

Expected a single terminal per task/cwd to be reused. Actual behavior creates additional terminals.

Expected Behavior

• If an idle terminal exists for the same task/provider, reuse it even if cwd has drifted.
• Optionally change directory in the reused terminal prior to running the next command.

Actual Behavior

• New terminals are created frequently, leading to terminal proliferation, even when reuse should be possible.

Code Investigation

Reuse decision path:

• Selection logic prefers same taskId and matching cwd, then any idle with matching cwd, else creates new:
  • TerminalRegistry.getOrCreateTerminal()
    • Task/cwd/provider match branch (not busy): checks cwd via arePathsEqual (TerminalRegistry.ts)
    • Fallback any idle same-cwd branch: (TerminalRegistry.ts)
    • Creation when no match: TerminalRegistry.createTerminal() → VS Code terminal via Terminal()
• VS Code terminal run path sets busy and relies on shell execution events to clear it:
  • Terminal.runCommand()
  • Busy toggled by VS Code events: start/end handlers (TerminalRegistry.initialize(), TerminalRegistry.initialize())
• Provider selection impacts reuse; fallback to execa creates a different provider pool:
  • Provider branch: executeCommand()
  • Acquisition: TerminalRegistry.getOrCreateTerminal() call

Why reuse can fail:

• CWD drift: If terminal’s current cwd (from shell integration) differs from requested cwd, the equality check fails and a new terminal is created.
• Provider mismatch: Switching between “vscode” and “execa” (due to shell integration fallback) partitions terminals by provider, preventing reuse.
• Busy flag timing: If a terminal remains marked busy momentarily, reuse is skipped and a new terminal is created.

Proposed Direction

• Add a third-priority reuse fallback:
  • If no cwd-match exists but there is an idle same-provider terminal (prefer same taskId), reuse it and prepend cd "<requestedCwd>" && before the command.
• Or relax the task-first branch:
  • Reuse same-taskId terminal regardless of cwd (send a cd to requested cwd when needed).
• Keep current behavior behind a setting:
  • “Reuse terminal across directories” (default on) to control fallback behavior.
• Ensure provider consistency or allow reuse across providers when semantically equivalent.
• Add unit tests:
  • Reuse with cwd drift (shell integration reports different cwd).
  • Reuse across repeated commands for same task/cwd.
  • No new VS Code terminal created when an idle candidate exists.

Additional Notes

• Creation path: TerminalRegistry.createTerminal() → Terminal()
• Execution path: TerminalProcess.run()

[roomote]

I'm exploring a potential fix for this issue where MCP server errors are not being surfaced to the UI. I'll investigate the error handling paths and work on ensuring user-visible feedback for connection/refresh failures.