Windows 11 version 22H2 landed with a quiet but impactful change: Command Prompt, Windows PowerShell, and any other console application now launch inside Windows Terminal by default. After applying the October 2022 cumulative update or performing a clean install of 22H2, clicking a .cmd file, running a batch script, or opening PowerShell from the Win+X menu no longer brings up the classic console host (conhost.exe). Instead, the Windows Terminal app springs to life, hosting the requested shell in a tabbed, modern window. Microsoft positions this as a step toward a unified command-line experience, but the shift has sparked debates among IT professionals, developers, and power users who rely on the old behavior for scripting, accessibility, and compatibility.

The change is rooted in a feature introduced earlier in Windows Terminal’s development: the “Default terminal application” setting. In Windows 11 21H2 and earlier, this setting defaulted to “Windows Console Host,” meaning that even if Terminal was installed, the system would open traditional console windows unless explicitly configured otherwise. With 22H2, Microsoft flipped that switch to “Windows Terminal.” The result is that any native console application—cmd.exe, powershell.exe, pwsh.exe, wsl.exe, and even third‑party tools that use a console subsystem—now renders inside Terminal’s user interface.

Why Did Microsoft Force the Change?

Microsoft’s reasoning is straightforward. Windows Terminal offers a richer environment: multiple tabs, panes, GPU‑accelerated text rendering, extensive customization, and better support for Unicode and modern text features. By making it the default, the company ensures that even casual users benefit from these enhancements without digging into settings. For developers working with the Windows Subsystem for Linux, integrated terminals are table stakes, and Terminal delivers that seamlessly. The move also aligns with the broader deprecation of the classic console host, which will eventually enter maintenance mode only.

However, the transition isn’t seamless for everyone. The classic conhost served as more than a simple window—it managed console APIs that some legacy applications still rely on. When a process is launched inside Terminal, it communicates through a pseudo‑console (ConPTY) layer, which translates traditional console API calls to Terminal’s rendering pipeline. While this abstraction works well for most modern tools, it can introduce subtle incompatibilities.

The Fallout: Compatibility Headaches

After the 22H2 rollout, Windows forums and feedback channels lit up with reports of broken workflows. The most commonly cited issues fall into three categories: accessibility, user‑interface quirks, and API‑level incompatibilities.

1. Accessibility Regressions

Screen reader users encountered a significant degradation. Narrator, JAWS, and NVDA have long‑standing integrations with the classic console host that read output line‑by‑line and expose the command history through standard accessibility interfaces. When the same cmd.exe process runs inside Windows Terminal, the accessibility tree changes dramatically. Terminal is built on a UWP‑style framework that uses a custom text buffer; screen readers must speak the visual content of the terminal control as a single text block rather than a structured console. This can lead to repeated announcements of the entire buffer, loss of cursor tracking, and an inability to review output efficiently. Microsoft acknowledged the gap and has been iterating on Terminal’s accessibility, but as of early 2023, many assistive‑technology users were forced to revert to the classic console.

2. Visual and Behavioral Differences

Even sighted users notice the difference. The classic console window respects system‑wide title bar and border settings, uses the system cursor blink rate, and can be resized with familiar snapping behavior. Terminal introduces its own title bar, tab row, and a different approach to window chrome. For users who have automated window positioning via tools like AutoHotkey or that depend on specific window class names (ConsoleWindowClass), the switch breaks automation. Additionally, ConsoleHost supports quick‑edit mode and mark‑and‑paste behaviors that differ from Terminal’s default keybindings. Legacy batch files that relied on console‑specific features like mode con commands to set the window size or buffer dimensions may behave unexpectedly because Terminal manages its own dimensions.

3. UAC Elevation and Security Context

One subtle but critical difference arises when running elevated command prompts. The classic console host can launch a process as administrator and present the UAC consent dialog in a secure desktop. Windows Terminal, being a packaged app, handles elevation differently: it creates a new elevated Terminal window rather than elevating an existing tab. This can confuse scripts that assume a single persistent console instance. Moreover, certain security software and remote management tools inspect the process chain; seeing wt.exe instead of cmd.exe directly may trigger false positives or policy violations in locked‑down enterprise environments.

4. Legacy Console API Support

A small but vocal minority of users discovered that third‑party console utilities—especially those using low‑level color attributes, cursor teleportation, or direct screen buffer manipulations—render incorrectly inside Terminal. The ConPTY layer emulates the console API, but edge cases exist where colors are mapped differently, escape sequences aren’t handled identically, or the output flickers because of timing differences in buffer flushes. Software that uses the conhost window handle for inter‑process communication or for injecting input events also breaks under Terminal.

How to Revert to the Classic Console Host

If you’re among those affected, the good news is that Microsoft retained the ability to switch back. The setting is per‑machine (or per‑user with some registry tweaks) and doesn’t require uninstalling Windows Terminal. There are three straightforward methods:

Method 1: Via Windows Terminal Settings

  1. Open Windows Terminal (you can search for “Terminal” in the Start menu).
  2. Click the down‑arrow next to the tabs and select Settings, or press Ctrl + ,.
  3. In the Startup section (first page of the settings UI), locate the Default terminal application dropdown.
  4. Change the selection from “Windows Terminal” to “Windows Console Host”.
  5. Click Save. Close and reopen any console application; they should now appear in the classic window.

This GUI method is available in Windows Terminal 1.15 and later, which is pre‑installed with 22H2. If the setting is missing, update Terminal from the Microsoft Store.

Method 2: Via Group Policy or Intune (Enterprise)

For organizations that need to enforce the classic console across many machines, Microsoft provides a Group Policy administrative template (ADMX/ADML) for Windows Terminal. After importing the latest Terminal ADMX files into your Central Store, you’ll find the policy under:

Computer Configuration / Administrative Templates / Windows Components / Windows Terminal

The policy name is “Set Windows Terminal as the default terminal application” (or similar). Set it to Disabled to revert all consoles to the classic host. Intune users can deploy the same via a custom OMA‑URI setting or through the Settings Catalog when the policy appears.

Method 3: Direct Registry Edit

Advanced users can toggle the behavior per‑user or system‑wide through the registry. The relevant key is:

HKEY_CURRENT_USER\\Console\\%%Startup

The value DelegationConsole (DWORD) controls the default:
- 1 = Windows Terminal (default in 22H2)
- 0 = Windows Console Host

To deploy via script:

Set-ItemProperty -Path "HKCU:\\Console\\%%Startup" -Name "DelegationConsole" -Value 0

For system‑wide effect (all users), modify under HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Console\\%%Startup, but this requires careful testing as it overrides per‑user preferences.

Maintaining Compatibility Without a Full Rollback

Some users can’t abandon Terminal entirely because they rely on its modern features for WSL or Azure Cloud Shell. Others simply want a hybrid approach. Here are a few tactics to keep the best of both worlds:

  • Use the “Open in Windows Terminal” context menu: In the classic console, you can right‑click the title bar (or use the system icon) and select “Open in Windows Terminal” on demand, keeping the default as classic host.
  • Launch Terminal explicitly: Pin Windows Terminal to your taskbar and use it for WSL and PowerShell 7, while letting cmd.exe and PowerShell 5.1 open in the legacy host.
  • Configure specific profiles: In Terminal’s settings, under each profile (Command Prompt, PowerShell, etc.), you can set the “Command line” to the exact executable. If you want a profile that uses conhost regardless, you can create a custom profile that invokes cmd.exe with a special argument: cmd.exe /k “console:conhost” — though this is an unsupported hack and may close unexpectedly.
  • Toggle via environment variable: An undocumented trick involves setting WT_SESSION environment variable to an empty string before launching the console; if present, Terminal skips the pseudoconsole wrapping. However, this is fragile and not recommended for production scripts.

Community Workarounds and Reactions

Since the change rolled out, the conversation on Windows forums and r/Windows11 has been lively. Many IT administrators expressed frustration that the update broke logon scripts that had been running unchanged for a decade. One common refrain: “Our helpdesk tickets spiked because users couldn’t see the classic white‑on‑black cmd window and thought the system was broken.” The sentiment is not universally negative; developers who live in Terminal appreciate the streamlined workflow, but they acknowledge that forcing it on all console apps was too aggressive.

Several community‑driven fixes have emerged:

  • A PowerShell snippet that runs during image deployment to set the registry key before users log in.
  • A small AutoHotkey script that intercepts console launches and redirects them to a specific conhost window, giving back window‑snapping behaviors.
  • Discussion about whether Microsoft should implement a “compatibility mode” in Terminal that more faithfully emulates the classic console for older applications, similar to how browsers handle legacy web standards.

The Future: What’s Next for the Console Ecosystem?

Microsoft’s long‑term roadmap consolidates all command‑line experiences into Windows Terminal. The classic console host isn’t gaining new features and will eventually be removed from the default feature set, though it will remain as an optional component for backward compatibility, much like Internet Explorer. This means the current “Default terminal application” toggle is a temporary escape hatch; at some point, it may become a one‑way switch to Terminal only.

For users and organizations, now is the time to audit scripts, tools, and workflows that depend on conhost. Test them under Terminal with the ConPTY layer and address any issues. Screen reader users should engage with Microsoft’s accessibility team via the Feedback Hub to help prioritize the remaining gaps. Windows Terminal 1.17 and later are expected to bring substantial accessibility improvements, including UI Automation patterns that expose the text buffer more naturally to assistive technologies.

The change in Windows 11 22H2 may have been a surprise, but it’s a deliberate move toward a more cohesive developer experience on Windows. Whether you embrace it or roll it back, understanding how to manage the default console application is now an essential skill for anyone administering or using Windows professionally.