An AI coding CLI can run from PowerShell, another supported Windows shell, or a Linux environment through Windows Subsystem for Linux. The best option is usually the one that matches how the project builds and tests. Choose the environment first, then install the CLI according to its current instructions inside that environment.
Choose the shell your project expects
PowerShell is convenient when your project already uses Windows tools and commands. WSL gives you a GNU and Linux environment on Windows, which can be a closer match for projects whose scripts assume Linux utilities. Check the CLI vendor’s supported operating systems and shells because terminal agents do not all behave the same way.
Avoid switching shells halfway through a task. The agent, Git, package manager, and test command should see the same project files and environment. A path that exists in Windows may look different inside WSL, and shell syntax such as environment variable assignment can differ too.
Set up WSL as a separate development environment
Microsoft documents wsl --install as the standard starting point on supported Windows versions. After installation, open the Linux distribution, update it, and install the command line tools your project needs. If you use WSL, keep your project and its Git working copy in the environment you use to run the CLI. Microsoft’s WSL guidance explains file location and environment setup in more detail.
Install the coding agent inside the shell where you plan to use it. Sign in there, check which executable your shell resolves, and run its version or status command. Do not assume a Windows installation is automatically available inside a separate Linux distribution.
- Check whether the coding CLI supports your Windows shell.
- Choose PowerShell or WSL based on the project tooling.
- Keep the repository, Git, package manager, and agent in one environment.
- Run a harmless explain or plan request before allowing edits.
Avoid the common path and Git traps
A project opened in a Windows editor may still be running its tests through a Linux shell. Confirm the actual working directory before asking an agent to edit. Check line ending settings, executable file permissions, and whether the shell sees the same Git branch and uncommitted changes as your editor.
Do not open the same working tree for simultaneous writes through Windows and WSL. It is easier to reason about one Git state at a time, and file watchers can otherwise show confusing updates. Before a broad agent task, create a commit or branch so a change can be inspected and reverted cleanly.
Start with a small testable task
Ask the agent to locate the project test command, explain the relevant files, and make a small change with a clear check. Confirm that the command works in the chosen environment before asking it to run a full build. If the tool cannot start, record the shell, install method, working directory, and exact error before changing several environment settings at once.
For editor integration, use the editor’s documented WSL connection rather than opening a second copy of the project by hand. Then compare the terminal agent and editor from the same repository state.