Only a few months ago, Intelligent Terminal could be described fairly simply:

Windows Terminal, but with an AI agent integrated into a side pane.

That description is already becoming too narrow.

Microsoft is developing the project as an experimental, open-source fork of Windows Terminal, but during July and August 2026 it added enough pieces that the product is starting to look less like a “terminal with chat” and more like a host for development agents.

The difference is not semantic.

A chat inside a terminal can answer questions.

An agentic host has to solve much more structural problems:

Which agent runs this task?
Where does it run?
Which shell and filesystem does it see?
Which session should it resume?
Which model does it use?
Which commands can it propose?
How is it isolated from other tabs?
What happens when I close the window?

Over the last two months, Microsoft has attacked precisely those layers.

The direction is fairly clear:

Intelligent Terminal
       ↓
multipane terminal
+ interchangeable agents
+ ACP
+ WSL
+ local models
+ sessions
+ tool / command surfaces

And that makes the project one of the most interesting experiments around the idea of an agent-first shell.

First: what is Intelligent Terminal?

Microsoft announced Intelligent Terminal 0.1 on June 2, 2026 as an experimental fork of Windows Terminal with native agent integration.

The project inherits nearly all of Windows Terminal’s infrastructure —tabs, panes, profiles, shells, renderer, configuration— and adds a new layer around the Agent Pane.

Instead of forcing the user to keep a chatbot separate from the environment where work is happening, the agent lives beside the shell.

Conceptually:

┌───────────────────────────────────┐
│ Intelligent Terminal              │
│                                   │
│  ┌──────────────┐ ┌─────────────┐ │
│  │ PowerShell   │ │ Agent Pane  │ │
│  │ / WSL / bash │ │             │ │
│  │              │ │ ACP agent   │ │
│  └──────────────┘ └─────────────┘ │
└───────────────────────────────────┘

The important architectural piece is ACP — Agent Client Protocol.

Instead of hard-coding every AI CLI integration completely inside the terminal, Intelligent Terminal can communicate with agents through a common interface.

That reduces coupling between:

Terminal UI
   ↓
ACP
   ↓
Copilot / Claude / Codex / OpenCode / other agents

The July and August evolution makes more sense when viewed as an expansion of that abstraction.

July: sessions stop depending on each CLI

On July 10 Microsoft released Intelligent Terminal v0.1.1841.

The seemingly most technical improvement was also one of the most important over the long term: session history began to come directly from the agent through ACP session/list.

Previously, the terminal had to know implementation details of different CLIs and reconstruct their histories.

The architecture looked more like:

Intelligent Terminal
   ├── Copilot parser
   ├── Codex parser
   ├── another CLI parser
   └── agent-specific logic

That does not scale well.

If every new agent needs a special integration, the terminal ends up accumulating adapters and heuristics.

With session/list, responsibility changes:

Intelligent Terminal
        ↓
    ACP session/list
        ↓
      agent
        ↓
   its own history

The terminal asks.

The agent returns its sessions.

That may look like a small optimization, but it is exactly the kind of decoupling needed to support many agents without turning the host into a collection of exceptions.

The same release added F5 to refresh the session list and discover conversations created outside Intelligent Terminal without restarting the application.

Source: Intelligent Terminal v0.1.1841 — GitHub Discussion #402.

Pasting images into the Agent Pane

The July release also added support for pasting images with Alt+V.

A screenshot can be sent to the agent as an ACP image block.

That matters especially for debugging.

A flow that once looked like:

screenshot
  ↓
save file
  ↓
open external chat
  ↓
upload image
  ↓
explain context

can become:

terminal
  ↓
Alt+V
  ↓
agent receives screenshot

Final support depends on whether the agent and model accept images, but the terminal already provides the transport surface.

Shell context: the agent starts understanding where it really is

Another important July change improved awareness of the active shell.

This solves a very common problem in terminal assistants.

Suppose we do:

PowerShell
   ↓
wsl
   ↓
bash
   ↓
exit
   ↓
PowerShell

An agent that only observes text can end up with the wrong idea of the current environment and recommend Bash commands inside PowerShell, or the reverse.

Intelligent Terminal added mechanisms to better report the real shell identity and strengthened Autofix so it inspects the environment before suggesting solutions.

It also began checking:

  • whether a command really exists on PATH;
  • whether equivalent local scripts exist;
  • whether the user simply made a typo;
  • the effective working directory;
  • which shell is active.

The idea matters:

a terminal agent should not reason about a generic terminal; it should reason about the concrete process running in front of it.

August: Intelligent Terminal 0.2 changes scale

The major leap arrived on August 10, 2026 with Intelligent Terminal 0.2.

Microsoft described it as its biggest release up to that point.

The four main additions were:

local models
+ different agent per tab
+ first-class OpenCode
+ agents running inside WSL

Each solves a different limitation of the original model.

Official source: Microsoft — Intelligent Terminal 0.2 is here with local model support.

Local models: BYOM enters the terminal

0.2 added Bring Your Own Model — BYOM.

The user can configure an OpenAI-compatible endpoint by specifying:

Base URL
+
Model ID

That makes it possible to connect, for example, a local server based on Ollama.

The architecture can look like:

Intelligent Terminal
       ↓
Agent Pane
       ↓
Copilot or OpenCode
       ↓
OpenAI-compatible endpoint
       ↓
Ollama
       ↓
local model

The change has several implications.

Privacy

The model can run on the user’s own machine when the workflow and agent allow it.

Offline

Not every workflow has to remain permanently dependent on a cloud provider.

Experimentation

The user can test different models without Microsoft having to add explicit support for each backend.

Cost

Cost no longer has to be a remote per-token call and can shift to local hardware.

The idea fits Intelligent Terminal’s philosophy perfectly: the terminal tries to be the host; the model is interchangeable.

/agent: a different agent in every tab

Probably the most representative feature of 0.2 is /agent.

Each tab can select its own agent without affecting the others.

For example:

TAB 1
PowerShell
→ Copilot

TAB 2
Ubuntu / WSL
→ Codex

TAB 3
frontend repo
→ Claude

TAB 4
local experiments
→ OpenCode + Ollama

That changes the unit of isolation.

Before, it was easy to imagine Intelligent Terminal as:

one terminal
+
one assistant

Now the architecture is closer to:

one workspace
  ├── tab → shell + agent
  ├── tab → shell + agent
  ├── tab → shell + agent
  └── tab → shell + agent

Conversations remain isolated per tab.

That makes simultaneous workflows possible without changing an agent destroying the context of other tabs.

The official release even gives an explicit example: Copilot in one tab, Claude in another, and Codex in a third.

That is exactly what we would expect from a multi-agent host.

OpenCode becomes a first-class backend

OpenCode also joined the integrated lineup.

That means it no longer has to be configured as a generic custom agent for the main operations.

It can be used for:

  • chat in the Agent Pane;
  • Autofix;
  • resuming previous sessions;
  • session management;
  • tracking hooks.

This matters for a strategic reason.

Microsoft is not designing Intelligent Terminal exclusively as “the Copilot terminal.”

It is explicitly leaving room for other agents.

That dramatically increases the product’s potential value.

A closed host competes with every new agent.

An open host can become more useful as new agents appear.

The agent can live inside WSL

For many Windows developers, the real work environment is not Windows.

It is WSL.

The repository may live under Linux.

Dependencies are installed there.

Paths are Linux paths.

Tools are Linux tools.

Version 0.2 makes it possible to configure the Agent Pane and ?<prompt> delegation per profile, including agents installed inside a WSL distribution.

That removes an enormous source of friction.

Compare two architectures.

Agent on Windows looking into WSL from outside

Windows agent
   ↓
path translation
   ↓
WSL filesystem
   ↓
Linux tools

Agent running inside the same distribution

Ubuntu / WSL
   ├── repo
   ├── git
   ├── python
   ├── node
   ├── toolchain
   └── agent

The second is much more natural.

The agent shares:

  • filesystem;
  • PATH;
  • working directory;
  • commands;
  • configuration;
  • installed tools.

In agentic engineering, reducing those environment differences prevents a significant number of absurd errors.

The Agent Pane stops looking like a secondary console

0.2 also contains many UX improvements that together matter more than they appear to individually.

For example:

  • mouse scrolling and selection;
  • double-click for a word;
  • triple-click for a line;
  • Unicode copy;
  • history of up to 50 prompts per tab using ↑ and ↓;
  • preservation of drafts and multiline prompts;
  • tool calls with animated states;
  • visualization of paths and commands touched by the agent;
  • status bar with tokens and cost;
  • pane-aware colors;
  • search inside /sessions;
  • /move to place the Agent Pane at the top, bottom, left, or right.

Individually, these are details.

Collectively, they point to something else:

Microsoft expects users to spend enough time inside the Agent Pane that it needs the ergonomics of a primary tool, not a demo.

Autofix is maturing too

Autofix began with an attractive idea: detect that a command failed and let an agent suggest a solution.

But doing that reliably requires interpreting errors from very different shells.

0.2 improved detection of:

  • Windows PowerShell 5.1 runtime errors;
  • PowerShell parser errors;
  • Bash prompt cycles;
  • command-not-found;
  • aliases defined in profiles;
  • local scripts;
  • the real working directory;
  • tools packaged with Windows Terminal.

In other words, Autofix is moving from:

"I saw an error; I will invent a plausible solution"

toward:

"I saw an error;
first I inspect the environment;
then I propose a fix"

That difference is fundamental for reducing operational hallucinations.

What is NOT delivered yet: Durable Sessions

Here it is important to separate shipped product from work in progress.

Microsoft has already announced that it wants to move Intelligent Terminal toward Terminal Session Restore.

The most interesting PR right now is #628 — Durable sessions: save & restore shell sessions across close and crash, opened on August 19.

As of this article, it remains open.

The goal is to persist information on disk such as:

tab and pane layout
+ profiles
+ working directories
+ agent bindings
+ optional scrollback
+ associated ACP session

The desired experience is powerful:

work in a tab
   ↓
close window / crash
   ↓
reopen Intelligent Terminal
   ↓
same tab
same panes
same cwd
same agent
same conversation

The PR uses persistent storage managed by wta-master, including SQLite for session state and sidecars for buffers.

It also introduces /tab-history to search, restore, and delete old sessions.

That changes the product substantially.

A traditional terminal feels ephemeral.

A durable terminal begins to behave like a persistent workspace.

And when it also preserves the agent conversation, the unit of persistence stops being only the shell.

It becomes:

shell + workspace + agent state

The next step: keep even the processes alive

PR #628 itself makes clear that it does not yet include the full ambition of Durable Sessions.

Persisting and reconstructing state is one thing.

Keeping the shell actually running after the interface closes is another.

The complete architecture Microsoft is exploring separates the two:

phase 1
save & restore state

phase 2
keep-running / detach

That could bring Intelligent Terminal closer to experiences we associate today with tools such as tmux, persistent remote sessions, or terminal multiplexers, but integrated with agent state.

Incremental Markdown inside the Agent Pane

Another active PR is #639 — Render agent responses as Markdown.

The goal is to render agent responses with Markdown structure while they stream:

  • headings;
  • lists;
  • code blocks;
  • links;
  • syntax highlighting.

It looks like a purely visual improvement.

It is not entirely.

As agents return longer plans, commands, diffs, explanations, and reports, formatting becomes part of operational readability.

An agentic host needs to represent structured content well.

Slash commands announced by the agent itself

PR #623 — Support ACP slash commands points to something even more interesting.

Today Intelligent Terminal knows its own commands such as:

/help
/fix
/model
/agent
/sessions

But an agent can have capabilities the terminal does not know in advance.

With slash commands announced through ACP, the agent could dynamically expose operations such as:

/plan
/review
/usage
/compact

without Intelligent Terminal having to implement each command as its own feature.

That better completes the abstraction:

host
 ↓
ACP capabilities
 ↓
agent announces commands
 ↓
UI presents them

Instead of building a fixed UI for every agent, the host discovers part of its capability surface.

That is a very powerful property for an open ecosystem.

Deterministic actions on panes

PR #607 — Add deterministic source-pane slash commands is also open.

Here the problem is different.

An agent can suggest a command, but in which pane should it execute?

When several shells exist simultaneously, relying only on current focus can be ambiguous.

The PR works on commands and actions directed to one specific pane, using a stable pane identity and action cards that can offer options such as:

Run
Insert
Adjust

That moves the system toward a safer separation:

agent proposes action
        ↓
terminal knows exact target
        ↓
user approves / modifies
        ↓
execution

In agentic systems, explicitly identifying the target is much better than depending on implicit context.

The architecture starting to emerge

Putting all these pieces together, Intelligent Terminal is beginning to describe an architecture quite different from a classic terminal.

┌────────────────────────────────────────┐
│ Intelligent Terminal                   │
│                                        │
│  Tab A                                 │
│  ├── PowerShell                        │
│  └── Copilot                           │
│                                        │
│  Tab B                                 │
│  ├── Ubuntu / WSL                      │
│  └── Codex                             │
│                                        │
│  Tab C                                 │
│  ├── experimental repo                 │
│  └── OpenCode → local Ollama           │
│                                        │
│  Shared capabilities                   │
│  ├── ACP                               │
│  ├── session management                │
│  ├── terminal actions                  │
│  ├── pane targeting                    │
│  └── durable session store             │
└────────────────────────────────────────┘

That is no longer simply “AI integrated into Terminal.”

It is a platform trying to coordinate agents, shells, sessions, and execution environments.

Why ACP may be the most important piece

It is easy to focus on visible features —Ollama, /agent, WSL— and miss the piece connecting them.

ACP lets Intelligent Terminal treat the agent as an external capability with defined contracts.

That progressively enables things such as:

session/list
session/load
slash commands
image content
model switching
agent-specific capabilities

The direction is similar to what MCP did for tools, but applied to the relationship between host and agent.

That separation has a strategic consequence.

If the protocol works well, Microsoft does not have to win the “best agent” race.

Intelligent Terminal can gain value simply by being an excellent place where many different agents can work.

From shell to agent-first workspace

For decades, a terminal had a very concrete responsibility:

user types command
        ↓
shell executes
        ↓
terminal shows output

Agents add another layer:

user expresses intent
        ↓
agent interprets
        ↓
inspects shell / repo / context
        ↓
proposes or executes actions
        ↓
terminal represents and controls
        ↓
shell executes

That turns the terminal into something closer to a local control plane for development work.

It does not mean the shell disappears.

The opposite happens.

The shell becomes the deterministic surface beneath the agent.

The agent can reason.

But commands, processes, paths, and results remain real and observable.

That combination is particularly attractive for software engineering:

probabilistic LLM
      ↓
explicit actions
      ↓
deterministic shell
      ↓
observable result

The risk: too much autonomy too soon

This direction also carries risks.

The closer the agent is to the shell, the larger its potential radius of action.

A wrong chatbot produces a bad answer.

A wrong terminal agent can produce:

rm
checkout
push
install
kill
terraform apply
kubectl delete

That is why details matter such as:

  • action cards;
  • explicit pane targeting;
  • visibility of tool calls;
  • visible paths and commands;
  • isolation per tab;
  • recoverable sessions;
  • separation between suggesting and executing.

The terminal can become a great agent host precisely because it is already a place where actions are explicit and auditable.

But that advantage disappears if the UI hides what is really being executed.

In two months, the project changed categories

The evolution can be summarized like this.

June

Windows Terminal
+
Agent Pane

July

Agent Pane
+
ACP session history
+
image paste
+
shell-aware context
+
PATH-aware Autofix

August — 0.2

multi-agent per tab
+
local models
+
OpenCode
+
WSL-native agents
+
richer agent UI
+
usage / cost visibility

Active work

durable sessions
+
agent session restore
+
Markdown streaming
+
ACP dynamic commands
+
deterministic pane actions

The trend is clear.

Microsoft is not merely adding more prompts to the terminal.

It is building infrastructure so the terminal can host different agents, preserve their context, and connect them safely to real shells.

Conclusion

Intelligent Terminal is still experimental.

We should not confuse open PRs with finished features or assume the current architecture will reach a stable release unchanged.

But the iteration speed of July and August 2026 reveals a very interesting direction.

The initial idea was:

terminal + AI

The architecture beginning to appear is richer:

workspace
  ↓
terminal panes
  ↓
interchangeable agents
  ↓
ACP
  ↓
cloud or local models
  ↓
actions on real environments
  ↓
persistent sessions

If Durable Sessions and ACP surfaces continue advancing, Intelligent Terminal could become something more important than a variant of Windows Terminal.

It could become a shell designed from the beginning for an era where the user no longer executes all the work directly, but coordinates agents working alongside them.

And that is the most interesting signal in the project.

The future of the terminal may not be hiding the command line behind AI.

It may be exactly the opposite:

use the command line as the verifiable substrate where multiple agents can work without losing sight of what is actually happening.

Sources