Shells & Workspaces

Shell detection

On startup the plugin enumerates every shell it can find on the machine and offers them in the session picker. Nothing is configured by hand unless you want it to be.

Shell	Where it looks
PowerShell 7 (pwsh.exe)	Program Files\PowerShell\7, the x86 equivalent, the Microsoft Store WindowsApps path, ~\.dotnet\tools, Scoop, and PowerShell\7-preview
Windows PowerShell	System32\WindowsPowerShell\v1.0\powershell.exe
Command Prompt	System32\cmd.exe
Git Bash	Program Files\Git\bin, ProgramW6432, the x86 path, LocalAppData\Programs\Git, and Scoop
WSL distributions	wsl.exe -l -q, one profile per distribution. Requires Windows build 19041+. docker-desktop distributions are filtered out.
Cygwin	%HOMEDRIVE%\cygwin64\bin\bash.exe, then cygwin
MSYS2	%HOMEDRIVE%\msys64\usr\bin\bash.exe

On POSIX platforms (retained in source for a future release) it detects $SHELL, /bin/bash, /bin/zsh and /usr/bin/fish.

Keep-alive flags

Shell commands are normalised before launch so the shell stays open instead of exiting immediately:

• PowerShell / pwsh get -NoLogo -NoExit appended if not already present.
• cmd.exe gets /Q /K.
• Anything else is left exactly as you wrote it.

Paths are quoted and normalised to backslashes for CreateProcessW, so a setting written as C:/Tools/mybash.exe works fine.

Setting a default

Default Shell (Windows) in settings takes an executable name or a full command line, arguments included:

pwsh
C:\Program Files\Git\bin\bash.exe --login -i
"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoExit

Leave it empty and the plugin falls back to PowerShell, and then to Command Prompt.

Working directory

New sessions start according to Working Directory Policy:

Policy	Starts in
Project Root (default)	Your .uproject directory
Engine Root	The engine install directory
Custom	The absolute path in Custom Working Directory

If a custom path is missing or unreachable, the session quietly reverts to Project Root rather than failing to start.

Workspace modes

Each terminal tab runs in one of three workspace modes.

Plain Shell

One plain shell process per session. No multiplexer, nothing extra running, nothing to install.

When you close the editor the process ends. On restart, the plugin recreates the session record — same shell, same tab, same split layout — but the shell itself is freshly spawned, so anything that was running in it is gone.

This is the default and it is the right choice for most people.

PSMux Workspace

psmux is a Windows-native, PowerShell-based multiplexer. In this mode the plugin wraps your shell in a named psmux workspace. Because psmux owns the process rather than the editor, the shell keeps running when the editor closes and re-attaches when you open it again — an agent mid-task survives an editor restart.

psmux transparently wraps any Windows child process, so it works with cmd, PowerShell, pwsh and Git Bash.

Not bundled

psmux is not shipped with the plugin and the plugin will never install it. Install it yourself:

winget install marlocarlo.psmux

Once it is on the machine the plugin auto-detects it via PATH, where.exe and the usual install locations. Open a new session to pick it up.

Tmux Workspace

For WSL profiles the multiplexer has to live inside the distribution, so those use tmux rather than psmux. The workspace is owned by the tmux server inside the distro, sessions survive editor restarts, and it behaves like an ordinary *nix tmux session in every other respect.

A standing rule

The plugin never writes to your shell profile. Not .bashrc, not your PowerShell $PROFILE, not .zshrc — not even a transient, opt-in edit.

This is deliberate and it is not going to change. Nothing the plugin does persists on your machine in a way that would need uninstalling, and no shell-integration script can rot out from under you when your shell updates. The cost is that a few tricks other terminals do with shell hooks are not available here; the benefit is that removing the plugin removes the plugin.