Group Policy settings

Wintty Pro Enterprise reads six managed settings from the registry under SOFTWARE\Policies\Wintty, in the hive the policy applies to. Set the values with the tooling you already run: Group Policy registry preferences, Microsoft Intune, or SCCM. This page documents what each policy writes and what the client does about it.

The policies are honored by Wintty Pro Enterprise, the edition packaged as a per-machine MSI for fleet deployment. No other edition constructs a policy reader, Pro Desktop included, so the values take effect only there.

All six values live under one key, written in the hive you want them to apply from. A value acts as a policy while it exists, and deleting the value un-manages that setting.

Hive	Key
Machine, every user	HKLM\SOFTWARE\Policies\Wintty
One user	HKCU\SOFTWARE\Policies\Wintty

Group Policy writes these through a registry preference: under Computer Configuration or User Configuration, Preferences, Windows Settings, add a Registry item. Intune and SCCM write the same values through their own registry settings or package steps.

The client reads each policy value from the first of five sources that has one:

1. HKLM\SOFTWARE\Policies\Wintty, machine policy
2. HKCU\SOFTWARE\Policies\Wintty, user policy
3. HKCU\SOFTWARE\Wintty, the user's own preference
4. The JSON configuration file
5. Built-in defaults

Earlier wins. A machine policy overrides a user policy, and either overrides the user's own settings. A policy also holds only while its value exists: UpdateChannel set to stable pins the channel, and deleting the value lets the choice fall through to the next source. To un-manage a setting, delete the registry value.

Source three is the user settings layer documented in Windows-Only Options.

All six write to the same key, SOFTWARE\Policies\Wintty, under the hive the policy is applied to. The value name matches the policy name in every case.

Policy	Value type	What it does
DefaultProfile	REG_SZ	Forces a profile by name or GUID and ignores the user's profile choice. 260 characters maximum.
UpdateChannel	REG_SZ	Pins the update channel: stable, beta, or tip. The value none disables automatic updates.
AllowedShells	REG_MULTI_SZ	Lists the shell executables the user may launch. An empty or missing list means no restriction.
DisableContextMenu	REG_DWORD	1 removes the Explorer "Open in Wintty" entry, 0 keeps it.
LogPath	REG_EXPAND_SZ	Redirects the app log to a fixed path. The value is expandable, so environment variables in the path resolve on each machine. 32767 characters maximum.
RequireDefaultTerminalHandoff	REG_DWORD	1 makes Wintty register itself as the default terminal, 0 unregisters it. See the next section.

Windows itself ships no policy for choosing the default terminal application. The setting lives in HKCU\Console\%%Startup as two values, DelegationConsole and DelegationTerminal, each naming a COM class by GUID. Windows Terminal has shipped its own Group Policy template for these values since Preview 1.22, and a fleet managing the choice another way deploys the two values per user with scripts or Group Policy registry preferences.

RequireDefaultTerminalHandoff is that job as one policy:

• Enabled. At startup, Wintty checks whether it holds the default terminal handoff and registers itself if it does not. The check re-runs on every launch, so a user who switches the default back in Windows gets reverted at the next start. Registration is idempotent: a machine already in compliance is left alone.
• Disabled. Wintty removes its own registration if one is present, and the machine returns to the user's choice.
• Not set. No value exists, and Wintty leaves the user's choice alone.

The implementation refuses one case. The handoff contract treats the all-zero GUID, {00000000-0000-0000-0000-000000000000}, as a value that names nothing. A build whose COM classes are still placeholders cannot honour the policy, and writing those placeholders into %%Startup would break the handoff for every program that reads it. Such a build logs a warning naming the policy and writes nothing. A machine where the policy cannot apply says so in the log, and an application failure here never blocks startup.

Note

Enabled and Disabled are both enforced states. If you want the default terminal chosen but not locked, leave the value unset and let users set it themselves.

UpdateChannel takes stable, beta, tip, or none. The first three pin every machine to a channel. none disables automatic updates.

Think before you set none: a machine that never updates itself never picks up security fixes either. If the fleet gets its terminal updates from your own pipeline instead, set the policy to none and ship each new MSI the way you ship everything else.

AllowedShells is a multi-string list of shell executables the user may launch: a name like powershell.exe or cmd.exe, or a full path such as C:\Windows\System32\bash.exe. A shell that is not on the list does not launch. The list governs what Wintty will launch, not what runs on the machine: a program started outside Wintty is unaffected.

An empty list behaves exactly like no policy. The client reads an empty value and a missing value as the same state, no restriction, so clearing the list hands control back to the user completely.

LogPath writes the app log to a fixed path of your choosing. The value is expandable, so a path like %ProgramData%\Wintty\logs resolves per machine. Point the fleet at one path and SCCM inventory or an audit collector finds the log in the same place on every machine.