Command Code on Windows
Windows is a fully supported platform, and you have two good ways to run Command Code on it.
Native Windows is fully supported too, and it is a first-class fallback rather than a lesser one: a real PowerShell tool, Windows-aware path and process handling, and the same session, permission, and taste behavior you get on macOS and Linux. Reach for it when WSL isn't an option - a locked-down machine, a Windows-only toolchain, or a project that has to build against Windows itself.
| Platform | Support |
|---|---|
| WSL (Windows Subsystem for Linux) | Fully supported - recommended on Windows |
| Windows (native) | Fully supported - PowerShell, Windows Terminal, Git Bash |
| macOS | Fully supported |
| Linux | Fully supported |
In WSL (recommended)
Set up WSL first, then install from inside the WSL shell exactly as you would on Linux:
Verify the install, then log in and start a session:
WSL is Linux, so the short alias is cmd there - every example in these docs
works verbatim, with nothing to rename.
On native Windows
Verify the install, then log in and start a session:
Note the alias: it is cmdc on native Windows, not cmd. See
The cmdc alias below.
Keep it updated
WSL runs a real Linux
kernel and a real POSIX shell inside Windows - it is not an emulation layer. That
is why it is the recommended way to run Command Code on Windows: your shell
scripts, hooks, Makefiles, and tooling all run against the environment they
were written for, and every command in these docs works exactly as printed.
Open PowerShell as Administrator and run:
This installs WSL 2 with Ubuntu by default. Restart when prompted, then open the Ubuntu app from the Start menu to set up your Linux username and password. From there, install Command Code inside the WSL shell.
Working in WSL
- Keep your repositories on the Linux filesystem.
~/code, not/mnt/c/code. Crossing the/mnt/cboundary is slow enough that file search runs with a 60-second deadline inside WSL instead of the usual 20. Move your projects over and everything gets dramatically faster. - Clipboard image paste needs an X server. WSL reports itself as Linux, so
ctrl+vimage paste requires WSLg (or another X server) withDISPLAYset. Without one it is a silent no-op - text paste is unaffected, and dragging an image file in still works. See Pasting images. - Your editor and IDE still work. VS Code's Remote-WSL extension opens a window connected to the WSL filesystem, and Command Code's IDE integration works from that terminal as usual.
On native Windows the short alias is cmdc, not cmd. Inside WSL it is
plain cmd, like every other platform - one more reason WSL is the smoother
path.
cmd is a reserved system command on Windows: every shell - PowerShell, Windows
Terminal, Git Bash - intercepts it and launches cmd.exe instead of Command
Code, so Command Code cannot claim that name. cmdc avoids the conflict
entirely.
Everywhere these docs write cmd, use cmdc instead:
| These docs say | On native Windows, run |
|---|---|
cmd | cmdc |
cmd login | cmdc login |
cmd --version | cmdc --version |
cmd -r | cmdc -r |
cmd update | cmdc update |
The full name command-code works unchanged on every platform. Shell code
blocks throughout the docs have a Windows tab that rewrites itself to
cmdc, so you can copy them as-is.
The single biggest difference between a rough Windows experience and a good one is the terminal you run Command Code in - not Command Code itself.
Do not use the legacy Windows Console Host (conhost.exe, the black window
you get from bare cmd.exe or an old PowerShell shortcut). It predates modern
terminal capabilities and mangles the rendering, color, and key handling that a
TUI depends on.
At minimum use Windows Terminal, which ships with Windows 11 and is a free install on Windows 10. For the best experience, use a GPU-accelerated terminal:
Complete guideChoosing a terminalWhy your terminal emulator matters more than you think, the full list of recommended terminals across platforms, and what breaks when you stay on the one your OS shipped with.
On native Windows, Command Code runs shell commands through a first-class
PowerShell tool - not bash emulated through a translation layer. (Inside WSL
this section doesn't apply: you get the real bash tool, exactly as on Linux.)
It discovers real PowerShell (preferring pwsh 7+, falling back to Windows
PowerShell 5.1), spawns it with -NoProfile -NonInteractive -EncodedCommand
(immune to cmd.exe quoting bugs), forces UTF-8 output, understands both $?
and $LASTEXITCODE, and persists the working directory across calls. Its own
fail-closed read-only classifier gives Windows the same no-prompt reads that bash
gets on Unix.
Background processes work the same way they do elsewhere: kill_shell resolves
ports to pids with Get-NetTCPConnection, then escalates taskkill /T → /F,
and never signals an unrelated process group.
The powershell tool's arguments and safety model, plus every other built-in
tool and how permissions apply to each.
Most shortcuts are identical across platforms. Two are worth knowing on Windows:
| Key | Note |
|---|---|
alt+m | Cycles permission mode. Use this in terminals where shift+tab doesn't reach the process. |
ctrl+v | Pastes an image from the clipboard. Clipboard image paste works natively on Windows with no extra setup. |
Inside a VS Code-based terminal (VS Code, Cursor, Windsurf), run
/terminal-setup once to install the shift+enter and shift+tab keybindings -
VS Code otherwise swallows both before they reach Command Code. See
IDE Integration.
Every bindable action with its stable id and default keys, and how to
override them in keybindings.json.
ctrl+g, /skills, and plan review open files with the $EDITOR environment
variable.
Windows (PowerShell)
Common values: code (VS Code), notepad, vim, nano, subl (Sublime Text).
- Quickstart - install, log in, and run your first prompt
- Interactive Mode - shortcuts, pasting, and terminal choice
- Tools - the
powershelltool and everything else - FAQs - frequently asked questions
- Discord - real-time help
- Email - support