---
type: "post"
id: "multiple-terminals-landed-in-delta-v0-22-5d4fd5"
slug: "multiple-terminals-landed-in-delta-v0-22-5d4fd5"
title: "Multiple terminals landed in Delta v0.22."
description: "Delta v0.22 adds multiple interactive terminals to a single agent thread."
retrieval_nugget: "Delta v0.22 adds multiple interactive terminals to a single agent thread. The change matters because a coding-agent conversation can now keep a development server, watcher, build, and ad hoc shell work alive in parallel while retaining their visible context inside the thread."
published_at: "2026-10-30"
updated_at: "2026-10-30"
record_date: "2026-10-30"
date_kind: "published_at"
topics: ["claude","claude-code","mcp"]
entities: ["Delta","Zed Industries","Delta v0.22","Claude Code","Figma MCP"]
related_patterns: ["harness-architecture-outlives-model-choice"]
novelty_label: "new_fact"
what_changed: "Delta v0.22 adds support for multiple terminals per thread."
prior_refs: ["memory:661ab89a-ba32-812d-a8d9-6dcddddb283c","memory:6240b80f-c07f-828e-ae3b-4b7ed0a6dcd4","memory:8831e36d-cb80-87fe-ab3b-5c0edf8d6755"]
source_url: "https://delta.dev/docs/agents/terminals"
source_urls: ["https://delta.dev/docs/agents/terminals"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:multiple-terminals-landed-in-delta-v0-22-5d4fd5"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/multiple-terminals-landed-in-delta-v0-22-5d4fd5/","markdown":"https://newruntime.com/posts/multiple-terminals-landed-in-delta-v0-22-5d4fd5.md","json":"https://newruntime.com/posts/multiple-terminals-landed-in-delta-v0-22-5d4fd5.json"}
---

# Multiple terminals landed in Delta v0.22.

## Retrieval answer

Delta v0.22 adds multiple interactive terminals to a single agent thread. The change matters because a coding-agent conversation can now keep a development server, watcher, build, and ad hoc shell work alive in parallel while retaining their visible context inside the thread.

## Summary

Delta v0.22 adds multiple interactive terminals to a single agent thread. The change matters because a coding-agent conversation can now keep a development server, watcher, build, and ad hoc shell work alive in parallel while retaining their visible context inside the thread.

## What happened

Delta’s terminal documentation describes a workflow in which interactive terminals run in the checkout attached to an agent thread. In v0.22, a thread is no longer limited to one terminal: a user can type `@!` to open a new terminal in a chosen worktree or recall an existing session. If a thread has several projects attached, the terminal picker offers a new terminal for each project, so the user chooses which checkout it should use. Delta also supports opening a terminal with the menu, a keyboard shortcut, or the command palette.

The terminal is interactive rather than a transcript-only command surface. It uses the system shell on the user’s machine, unless the local Default Shell setting overrides it. It starts in the same checkout used by the agent, which means terminal commands operate on the same files. When a terminal script changes files, Delta records those edits as a navigable diff in the thread. For supported shell code blocks, Delta can prefill a command into the terminal, but does not run it until the user reviews the input and presses Enter.

A key part of the release is lifecycle management. Sending a message leaves a frozen terminal snapshot in the thread while the underlying local session continues to run. Typing `!` can bring that same session back, including a process still in progress. With Background Mode enabled, a process can remain active while the user opens another terminal in the same thread. Delta lists examples: run an application server and ask the agent to test it, keep a file watcher or compiler in watch mode while the agent edits files, or let a long build continue during discussion or review. The interface exposes running background terminals and lets users bring one inline, scroll to it, stop one process, or stop all processes.

The documentation distinguishes this interactive environment from agent execution. Agent commands do not use the interactive terminal or its Default Shell setting. On macOS and Linux they run in `/bin/sh`; on Windows Delta uses Git Bash for POSIX commands and PowerShell for Windows-style tools and scripts. A Maximum Terminal Timeout rule can cap agent command duration locally and on Cloud Runners, including when an agent requests a longer timeout. That cap does not apply to interactive terminals. The documentation further states that terminal processes run locally and use the user’s checkout, tools, environment variables, and credentials. In shared threads, collaborators can see terminal blocks and changing output, but only the person who opened a terminal can type into it. A visible process is not replicated onto another collaborator’s machine, and quitting Delta or removing the thread stops sessions started by that app.

## What the archive adds

This is a new capability on a known Delta release thread. [Delta’s October release notes](https://newruntime.com/posts/release-notes-delta-docs-6253bf/) covered v0.21.0 features including shared-thread opening in Claude Code, Figma MCP support, and update commands. Version 0.22 extends the thread itself into a more capable local execution workspace.

## Trend signal

The release supports the pattern that [harness architecture outlives model choice](https://newruntime.com/patterns/harness-architecture-outlives-model-choice/). The material value here is not a new model: it is the runtime surface around an agent—worktrees, shell processes, background state, diffs, timeout rules, and collaboration visibility. Those controls shape what an agent-assisted development session can actually do.

## Why it matters

Many coding tasks are not a sequence of isolated commands. Developers commonly need a server to stay up while they inspect a UI, a compiler to watch files while an agent edits them, and tests or a build to run separately. Multiple terminals make that state available within one thread instead of forcing the user to stop processes, switch applications, or compress the situation into a prompt.

The source also draws useful operational boundaries. The agent’s command environment is distinct from the user’s interactive shell; timeout policy applies to the former; and sharing a thread shares visibility rather than remote control or process portability. Teams adopting agent workspaces should treat those distinctions as design constraints, especially where credentials, local environment configuration, and long-running processes are involved.

## What happens next

- **Delta adds richer coordination around concurrent terminal sessions.** (3 months, 60%). Watch for: per-terminal status, clearer agent access to live process output, or project-scoped controls.
- **Coding-agent workspaces make local-process boundaries more explicit.** (6 months, 65%). Watch for: separate execution policies for interactive shells, agent commands, and cloud runners.

## Limits and uncertainty

The documentation explains the intended workflow but does not provide adoption data, performance measurements, pricing details, or evidence that multiple terminals improve task completion rates. It does not state a numeric limit on live terminals. It also does not establish that an agent can directly control an interactive terminal; the source says the agent can temporarily inspect recent output after a sent snapshot, while the person who opened the terminal retains command input. Local environment behavior can vary by shell, operating system, installed tools, and repository configuration.

## Skill to build now

Set up a deliberate three-process local loop for one agent-assisted task this week: run the application server in one background terminal, keep a watcher or compiler in another, and use a third for tests or Git inspection. Before sharing the thread, verify which processes are local, who can stop them, and whether repository environment files should be reviewed before they are loaded.

## Reader takeaway

Multiple terminals turn a Delta thread from a single command lane into a workspace for concurrent local development processes. The useful part is not merely more shells: it is keeping process state, file changes, agent context, and team-visible output connected while preserving explicit control and execution boundaries.

## Open question

How much actionable live terminal output can an agent reliably use after a message snapshot, and how will Delta expose that capability as several background processes run at once?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Claude](https://newruntime.com/topics/claude.md): Explore the claude topic hub.
- topic hub: [Claude Code](https://newruntime.com/topics/claude-code.md): Explore the claude-code topic hub.
- topic hub: [Mcp](https://newruntime.com/topics/mcp.md): Explore the mcp topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)