Is computer control supported on Windows?

[Mikkelka]

Hi! I’m using Goose Desktop 1.57.0 on Windows and trying to understand the current state of computer control.

The Computer Controller extension is enabled, but in my session the available tools are for DOCX, PDF and XLSX files. I don’t see tools for controlling the mouse or keyboard, or taking screenshots. Goose was able to take a screenshot and move the mouse using Windows scripts, but I’m wondering whether there is a built-in or recommended way to do this.

Is computer control on Windows currently supported? If not, is that intentional, and are there plans or recommended alternatives for Windows users?

I found #13219, but I’m not sure whether it covers the broader question.

Thanks!

[QuantIntellect]

On 1.57.0, Windows has no built-in mouse/keyboard/screenshot tool. What you're already doing, running scripts through the Developer extension's shell tool, is the intended path.

What 1.57.0 ships

• Computer Controller registers only xlsx_tool, docx_tool and pdf_tool on every OS. computer_control is added only on macOS, as a Peekaboo wrapper (feat: computer controller overhaul, adding peekaboo #7342): mod.rs#L846-L853.
• On other OSes its instructions say: "Use the shell (developer extension) for system automation and scripting tasks." (#L342-L345)
• computercontroller prompt references a screenshot tool that no longer exists #13219 doesn't cover the broader question. It's only about the prompt's "There is already a screenshot tool available" line, which is wrong. Its fix, fix(computercontroller): stop telling the model a screenshot tool exists #13279 (merged to main, not in a release yet), replaces that line with telling the model to save a capture from a script and open it with read_image, i.e. your workflow. It adds no Windows tool.

Intentional? Yes. #11198's description (and #11199) still say Windows/Linux computer_control would be kept, but the merged diff deleted it (platform/windows.rs and the non-mac handlers), so 1.47.0 was the first release without it. When the Codex review bot flagged the removal, the PR author replied: "Intentional: on Windows/Linux computer_control was just a raw script runner, which the developer shell already covers (and is where adversary review applies by default). Making the removal explicit is the point of this PR…" Another maintainer then approved and merged it.

Plans? I couldn't find any for a Windows equivalent of Peekaboo, and the Q4 roadmap (#13028) doesn't mention computer use. Your #13289 is where to make the case; CONTRIBUTING.md routes feature requests through issues, so an issue linking #13289 is what gets triaged.

Practical setup

1. Set GOOSE_SHELL=powershell (setx GOOSE_SHELL powershell, then fully quit and reopen goose). On Windows shell defaults to cmd, where goose rejects multi-line commands (shell.rs#L104-L107, #L259-L266, docs). With PowerShell, shell makes the same powershell -NoProfile -NonInteractive -Command call the removed Windows computer_control made, so you're not missing anything.

2. Save a screenshot, then read_image it (it can also crop to zoom in):

   Add-Type -Name Dpi -Namespace W32 -MemberDefinition '[DllImport("user32.dll")] public static extern bool SetProcessDPIAware();'
   [W32.Dpi]::SetProcessDPIAware() | Out-Null   # real pixels on scaled displays
   Add-Type -AssemblyName System.Windows.Forms, System.Drawing
   $r   = [System.Windows.Forms.SystemInformation]::VirtualScreen
   $bmp = New-Object System.Drawing.Bitmap $r.Width, $r.Height
   $g   = [System.Drawing.Graphics]::FromImage($bmp)
   $g.CopyFromScreen($r.Location, [System.Drawing.Point]::Empty, $r.Size)
   $out = Join-Path $env:TEMP 'goose-screen.png'
   $bmp.Save($out, [System.Drawing.Imaging.ImageFormat]::Png)
   $g.Dispose(); $bmp.Dispose(); $out; "origin: $($r.X),$($r.Y)"

   read_image needs a model that accepts images, and goose doesn't downscale them. Bedrock rejects images over 2000 px once a chat has many of them (Amazon Bedrock request fails when an image exceeds the 2000px limit in multi-image requests #12575), so crop to a region under 2000 px there. The chatgpt_codex provider drops images returned by tools entirely (chatgpt_codex: images in tool results are dropped #12811). On multiple monitors you can capture just [System.Windows.Forms.Screen]::PrimaryScreen.Bounds instead (origin 0,0, smaller image).

3. Mouse/keyboard: [System.Windows.Forms.Cursor]::Position, [System.Windows.Forms.SendKeys]::SendWait(), or user32 SendInput for clicks. Call SetProcessDPIAware there too, so cursor coordinates are in the same physical pixels as the screenshot: screen position = image pixel + the printed origin (0,0 unless a monitor sits left of or above the main one). SetProcessDPIAware assumes every monitor uses the main one's scaling, so monitors scaled differently can still be off.

4. For element-level UI control, add a Windows MCP server as a custom extension (Extensions → Add custom extension → Standard IO), e.g. CursorTouch/Windows-MCP with Command uvx --python 3.14 windows-mcp serve. Goose Desktop bundles its own uvx for extensions, so you don't need to install uv first. Windows-MCP's current release requires Python 3.14+, and --python 3.14 has uv download it if you don't have it. The first start can take a minute or two while it installs; if it times out, retry. It sends anonymous telemetry unless you add ANONYMIZED_TELEMETRY = false under Environment Variables in the same dialog. I haven't tried it with goose myself.

[Mikkelka]

Thanks for the detailed explanation! That clears up why the Windows computer control tools are no longer available and how the shell-based approach fits in.

Windows-MCP looks interesting. I haven’t tested it with Goose yet, but I’d like to explore it as a possible way to get a more complete computer-use experience on Windows.

I’ve also started a separate discussion about making computer use a higher priority for Goose, including whether existing open-source projects could be integrated or recommended.

Thanks again for taking the time to look into this!