Intelligent Terminal 0.2 makes the agent a per-profile choice

Microsoft released Intelligent Terminal 0.2 on August 10, 2026. The experimental Windows Terminal fork can now switch agents per tab, assign agents to individual Windows or WSL profiles, and send work through a model endpoint running on the same machine.

For a development team, that flexibility changes what “we use Intelligent Terminal” means. Two tabs in the same application may use different agent programs, models, shells, working directories, and credentials. This article explains those layers in order and shows how to test one configuration before making it a team default.

What can change from one tab to another?

The new /agent command lets a user choose a different installed, policy-allowed agent for each tab. Microsoft lists GitHub Copilot and OpenCode among the supported choices, while the project README says any Agent Client Protocol-compatible agent CLI can be configured. Changing the agent in one tab does not disturb the others.

The model is another choice. Intelligent Terminal’s bring-your-own-model setting accepts a Base URL and Model ID for an OpenAI-compatible Chat Completions endpoint. Microsoft documents Ollama as one local option and says the route works through GitHub Copilot or OpenCode. The /model command can then change the selected model for an Agent Pane.

A terminal profile adds a third layer. A PowerShell profile can use a Windows-hosted agent, while an Ubuntu profile can use an agent installed inside that WSL distribution. Profiles without an override continue to use the global default. The visible application frame therefore does not identify which agent process is handling the request.

Where does the agent actually run?

Microsoft says the ?<prompt> shortcut can execute inside the active WSL distribution and fall back to a Windows-hosted CLI when needed. A WSL profile can also select a distro-local agent. These are useful capabilities when source code, package managers, and build tools live inside Linux rather than on the Windows filesystem.

They also make location an operational fact instead of a visual assumption. The agent program may run on Windows or inside a WSL distribution. Its model endpoint may be local or remote. A command it proposes may target PowerShell, a WSL shell, or another shell profile. The working directory and available credentials follow that environment, not the terminal window’s branding.

Microsoft does not describe this as a privilege boundary, and the release does not report a security failure. The practical issue is configuration clarity: a result from one tab does not establish what another tab can read, execute, or reach.

Does a local model make the whole workflow offline?

Version 0.2 makes a local model easier to select. The project README says API keys are not stored for bring-your-own-model providers, which suits local endpoints such as Ollama that do not require one. Microsoft describes local-model workflows as private, offline, and free of cloud dependencies.

Treat that wording as a claim about the documented local-model route, not proof about every component attached to a workflow. An agent CLI can have its own authentication, update, telemetry, or service behavior. Package managers, browsers, tools, and commands can still reach external systems. The three source pages do not provide a complete network-flow audit for every supported agent and configuration.

If offline operation is a requirement, test it directly. Preload the model and dependencies, disconnect unapproved network paths, and run the representative task. Record outbound connection attempts from the terminal, agent CLI, model server, shell command, and any tool process. A completion from a local endpoint proves where model inference occurred; it does not by itself account for the rest of the workflow.

How should a team test one profile?

Start with a task that is representative but reversible, such as diagnosing a failing test in a disposable repository. Choose one named terminal profile and record whether it launches PowerShell, Command Prompt, or a specific WSL distribution. Pin the profile’s agent instead of relying on whichever global default happens to be active.

Next, record where the agent executable comes from and which model it selects. For WSL, verify that the intended distro-local binary is running rather than assuming the active profile forced that outcome. Capture the model Base URL and Model ID without placing secrets in the test record.

Submit the task from the intended working directory. Intelligent Terminal’s README says the Agent Pane can use shell output across PowerShell and Bash/WSL, so include the exact shell and directory in the evidence. When the agent suggests a command, use the product’s run-or-copy choice to inspect it before execution. Confirm that path syntax, environment variables, package manager, and file effects match the active environment.

Then repeat the task after opening a second profile with a deliberately different agent or shell. The expected result is not identical prose. The important outcome is that a reviewer can tell which process, model, shell, directory, and credentials produced each proposed action before approving it.

These are BaristaLabs recommendations, not controls Microsoft claims to enforce automatically. Teams should verify the installed build and their own agent policies because the project is explicitly described as experimental.

What should become the team default?

A useful default minimizes silent variation. Set the global agent and model only for profiles that truly share the same workflow. Use profile overrides when Windows and WSL projects require different binaries, package managers, or credentials. If users can switch agents with /agent, decide whether that is normal experimentation or a controlled exception for shared repositories.

Keep the approval description concrete: name the terminal profile, agent location, agent, model endpoint, shell, working directory, and credential scope. This is more useful than approving “Intelligent Terminal” as a single tool because version 0.2 intentionally makes several of those choices independent.

The feature is ready for a bounded evaluation when the team benefits from switching agents or keeping Linux work inside WSL and can inspect every proposed command. Standardization should wait until the same profile reliably selects the intended agent and model, enters the expected working environment, and produces actions that reviewers can attribute to that context.

Intelligent Terminal 0.2 makes a terminal tab a configurable agent workspace rather than a fixed client. If your Windows development team wants help defining one safe default across PowerShell and WSL, ask BaristaLabs to review the workflow.

Sources

• Microsoft Windows Command Line: “Intelligent Terminal 0.2 is here with local model support”, August 10, 2026.
• Microsoft Intelligent Terminal v0.2 release, published August 10, 2026.
• Microsoft Intelligent Terminal README, retrieved August 14, 2026.