DEV Community

TaskHandoff
TaskHandoff

Posted on

Codex on Windows keeps fighting PowerShell — run it in a Linux container instead

#opensource #devtools #ai #docker

If you run a coding agent on Windows for long enough, you'll notice a pattern: the agent writes a shell
command, it fails, it rewrites the command, it fails again — three or four times — and only then finds
something that works. On macOS or Linux the same task usually goes through on the first try.

It's tempting to blame the model. Usually it isn't the model. It's the shell layer underneath it.

What's actually happening

On native Windows, Codex doesn't hand your command to the OS as a plain argv list. External CLI
commands get wrapped and executed through PowerShell — closer to
pwsh.exe -Command "your-command ..." than a direct invocation
(#15294).

That single design decision cascades:

  • Quoting and escaping. PowerShell has its own quoting rules. A command that's perfectly valid in bash can need different escaping here — and the model has to guess which dialect it's writing for.
  • Permission rules stop matching. Because every command is rewritten into a PowerShell wrapper, allow-rules like "everything starting with dotnet" don't match reliably (#8537), which is why so many Windows users end up approving every single command (#2860, 77 comments).
  • Basic file operations go through the shell too. Even read/write/search were reported as PowerShell operations rather than internal tools (#3800).
  • Environment leaks. A child powershell.exe can inherit PowerShell 7's PSModulePath, which breaks module discovery and makes even Get-FileHash unavailable (#27117).
  • Sandboxing is flaky. Sandboxed PowerShell commands intermittently fail before the command even runs (#25497).
  • It's noisy. Every command can flash a console window (#48074, #48422).

The requests keep coming: people have asked, repeatedly, for a configurable Windows shell
(#16717, #31548,
#16579). Which tells you the community has already reached the
obvious conclusion: the shell layer is the problem, not the task.

The retry loop is what actually costs you

A failed command isn't just a wasted second. The agent has to reason about why it failed, produce a
different command, and try again — each round trip carries the whole context with it. On Windows this
can happen several times per task, and you pay for all of it in tokens and in your own attention.

The usual workarounds, and what they cost

  • WSL. Works, but now you maintain two environments, and the agent may or may not be running where your project actually lives.
  • Switch to Git Bash as the primary shell. Codex has been reported to chain Git Bash → PowerShell in confusing ways (#7298).
  • Approve everything. Fast, and exactly as bad an idea as it sounds.
  • Wait for a config option. Reasonable, but you're blocked on someone else's roadmap.

A different move: stop running your agent on Windows

TaskHandoff is an open-source control plane (Apache-2.0) for running and managing AI/Codex workspaces
across local and remote machines. Instead of fighting the host shell, each session runs inside a managed
Linux Docker workspace — and you drive it from one console.

Concretely, that means:

  • The agent always sees the same bash environment, whether the machine underneath is Windows, macOS, or Linux.
  • Docker workspaces are created, started, stopped and restored as first-class objects — no more "it worked on my other machine".
  • Environment templates let you snapshot a container's toolchain and reuse it, so a working setup doesn't have to be rediscovered per project.
  • Multi-node management puts local and remote machines on one board — run heavy work on a Linux box and still drive it from your Windows laptop.
  • AI session center streams session state in real time over WebSocket.

You don't need to teach the model PowerShell. You just stop asking it to.

Quick start 

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh
Enter fullscreen mode Exit fullscreen mode

Ships as a Desktop app and a server (systemd on Debian/Ubuntu), with an English/Chinese UI.

Honest caveats

Running your workspace in a container doesn't magically fix every Windows problem — if your project
genuinely needs Windows-only tooling, you'll want a Windows node. But for the large class of tasks where
the agent is looping on shell syntax and permissions, removing the host shell from the equation is the
cheapest fix available today.

Top comments (0)