DTDeepSeek TUI GuideTerminal setup and usage hub
Home/Install/Windows
Windows Install

Install CodeWhale on Windows by matching the package path to the shell you actually use every day

If you searched for DeepSeek TUI on Windows, the current upstream name is CodeWhale. Windows is where install confusion grows fastest because the shell, PATH rules, and terminal habits vary much more than on macOS or Linux.

Site detail pageInstall CodeWhale on Windows (DeepSeek TUI Rename Guide)Install

DeepSeek TUI has been renamed to CodeWhale

Upstream now ships the project under the new name. For fresh installs, use npm install -g codewhale and launch it with codewhale.

The older deepseek and deepseek-tui names still exist as compatibility shims for now, but upstream documents them as transitional and scheduled for removal in v0.9.0.

Questions this page should answer fast

  • Which Windows shell is the real owner of your CLI workflow?
  • When should npm, cargo, or WSL be preferred on Windows?
  • What proves the install succeeded beyond a single one-off shell session?

What to verify next

  • Run `codewhale --version` in the shell you will actually use for work.
  • Check whether PATH changes only exist in one terminal profile.
  • If the binary exists but requests fail, move into provider setup next.

Common mistakes

  • Testing in PowerShell but doing real work later in Git Bash or WSL.
  • Installing through a package path that your main shell does not already trust.
  • Assuming one successful run means the PATH is fixed for all terminal profiles.

Recommended reading order

Move through the page by workflow need first, then branch into adjacent detail pages or hubs.

Step 1

Identify the true shell first

Do not start from the install command. Start from whether your real sessions happen in PowerShell, Git Bash, or WSL.

Step 2

Match the ecosystem to that shell

Use the package path that already behaves normally there instead of forcing an unfamiliar toolchain.

Step 3

Validate after reopening

Windows path issues often appear only after a new shell session, so reopen the terminal and verify again.

Use-it-now examples

Start from working examples first, then adjust the details.

Test in the shell you really use for work

Windows setup only counts in the shell that will own your daily workflow, not just the shell where installation happened to succeed once.

codewhale --version
where codewhale

Separate Windows shell paths before changing package ecosystems

If PowerShell, Git Bash, and WSL disagree, compare their binary paths first before you reinstall through another toolchain.

where codewhale
# repeat in the exact shell profile you plan to use

Check version and path together after restart

On Windows, version success without path consistency is not enough. Reopen the exact terminal profile and verify both again.

codewhale --version
where codewhale
# repeat after opening a new PowerShell, Git Bash, or WSL session

Common failure branches

Work out which layer failed first instead of treating every problem as the same.

PowerShell works but Git Bash or WSL does not

Treat that as a shell-boundary or PATH-boundary issue first. Do not assume the package manager itself is broken.

The command exists but only inside the install shell

That usually means PATH propagation or terminal-profile scope is incomplete. Reopen the target shell and inspect which path actually resolves.

The path looks right but requests still fail only in one shell

That often means auth or env exports differ by shell profile. Move from install debugging into env and provider checks.

When to leave this page

Once the route is clear, leave this page quickly. Install pages should hand you into config, config pages should send you into provider or troubleshooting, and MCP or mode pages should send you back into live workflow decisions. A detail page is valuable because it narrows the problem, not because you stay on it forever.