Skip to content

Terminal Tools for Agents: send_to_terminal and Background Interaction

VS Code 1.115 adds send_to_terminal and the backgroundNotifications setting, giving agents bidirectional control over background terminal processes — eliminating polling and enabling recovery from interactive stalls.

The Problem

Agents running terminal commands face two gaps:

Read-only background access. Before VS Code 1.115, once a foreground terminal timed out and moved to the background, it became read-only. get_terminal_output could sample its output, but agents could not send input. An SSH session waiting at a password prompt, or a REPL waiting for a command, would stall indefinitely.

Passive polling for completion. Agents had no way to know when a background command finished or needed input. The only option was to call get_terminal_output repeatedly — wasting turns and introducing latency before the agent could react.

Two New Primitives

VS Code 1.115 (April 8, 2026) introduces two capabilities that address these gaps directly, and VS Code 1.116 (April 15, 2026) generalised both to any visible terminal and flipped the notification setting on by default.

send_to_terminal

The send_to_terminal tool lets an agent write input to any terminal visible in the panel — background terminals that timed out, and as of VS Code 1.116 foreground terminals a human started too. Interactive sessions stop being one-way black boxes.

Concrete use cases:

  • SSH with password prompt — the foreground terminal times out; the agent uses send_to_terminal to deliver the password without restarting the session (see sensitive terminal prompt interception for keeping the secret out of the model's context when this path is in use)
  • REPL interaction — keep a long-running Python or Node REPL alive and issue commands as needed
  • Dev server with runtime prompts — some servers prompt for confirmation on file changes; the agent can respond without manual intervention
  • Test watcher commands — send filter commands or rerun triggers to a watching test runner

backgroundNotifications

The chat.tools.terminal.backgroundNotifications setting eliminates polling. The agent receives an automatic notification when a background terminal command finishes or requires input — including terminals that were foreground and timed out. The setting shipped as experimental in VS Code 1.115 and is enabled by default in VS Code 1.116+, so most users get this behavior without configuration.

The agent can then act immediately: call get_terminal_output to review the result, or call send_to_terminal to provide the needed input.

Override the default in VS Code settings:

{
  "chat.tools.terminal.backgroundNotifications": false
}

Set to true explicitly only on VS Code 1.115; on 1.116+ it is already on.

How the Primitives Compose

The three terminal tools form a complete async I/O loop for background processes:

sequenceDiagram
    participant A as Agent
    participant T as Background Terminal
    A->>T: (foreground) run long command
    Note over T: times out → moves to background
    T-->>A: backgroundNotifications: needs input
    A->>T: send_to_terminal(input)
    T-->>A: backgroundNotifications: finished
    A->>T: get_terminal_output
    T-->>A: final output

Without backgroundNotifications, the agent must poll get_terminal_output in a loop, inferring completion from output changes rather than an explicit signal. Without send_to_terminal, the agent is blind-ended when a process waits for input.

Comparison: VS Code vs. Claude Code

Both VS Code Copilot and Claude Code solve the "agent needs to react to async terminal events" problem, but through different mechanisms:

Capability VS Code Copilot Claude Code
Write to terminal send_to_terminal tool Bash tool (new subprocess only)
React to background events backgroundNotifications setting Monitor tool (streams stdout)
Background read get_terminal_output tool Bash + polling (source)

VS Code uses a setting to push events to the agent; Claude Code exposes Monitor as a dedicated streaming tool where each stdout line arrives as a notification. Both avoid the polling loop, but the integration point differs — a setting vs. a tool call.

Example

An agent managing a development workflow starts a Next.js dev server in a terminal, continues work in other files, then needs to check if the server is ready:

Without backgroundNotifications:

Agent turn 1: [run terminal command: npm run dev]
Agent turn 2: get_terminal_output() → "Starting..."
Agent turn 3: get_terminal_output() → "Starting..."  ← polling
Agent turn 4: get_terminal_output() → "Ready on :3000"

With backgroundNotifications:

Agent turn 1: [run terminal command: npm run dev]
[agent works on other files]
Notification received: background terminal finished
Agent turn 2: get_terminal_output() → "Ready on :3000"

The agent recovers those polling turns and receives the signal with lower latency.

Key Takeaways

  • send_to_terminal gives agents write access to background terminals, enabling recovery from interactive stalls like SSH password prompts and REPL input waits
  • backgroundNotifications (chat.tools.terminal.backgroundNotifications, default-on as of VS Code 1.116) pushes completion and input-needed events to the agent, eliminating get_terminal_output polling loops
  • get_terminal_output (read) + send_to_terminal (write) + backgroundNotifications (event) form a complete async I/O model for background terminal process management
  • Claude Code's Monitor tool fills the equivalent role in Claude-based agent workflows by streaming background process stdout as notifications

When This Backfires

Behavior change between minor releases. The setting shipped experimental in 1.115 and became on-by-default in 1.116 a week later. Workflows that branched on its presence — or that assumed the agent would poll because the setting was off — silently changed shape on upgrade. Treat the notification surface as a moving target across minor VS Code updates and retest the agent loop after each.

Version lock-in. send_to_terminal and backgroundNotifications are VS Code 1.115+ features, and the foreground-terminal extension to send_to_terminal requires 1.116+. Teams pinned to an older VS Code version, or using a different IDE entirely, cannot adopt this pattern. Falling back to get_terminal_output polling is still required in those environments.

Notification reliability. The backgroundNotifications event fires when the shell reports process exit or input-wait status. Processes that stall without exiting (hung network calls, deadlocked threads) produce no notification — the agent waits indefinitely unless a separate timeout is enforced. The polling loop the setting replaces can at least detect output staleness.

Last reviewed: 2026-05-27
Feedback