Test your desktop app from Claude Code

Claude Code asks Sai to install your latest build on a Windows or Linux cloud computer and click through launch, sign-in, open, save and settings like a user. Failures come back with screenshots, Claude Code writes the fix, and Sai runs the flow again.

Paste into Sai, or send it from your agent
Use Sai to test the latest Windows build of our desktop app, the way a new user would, and report what breaks.

Build: the newest installer on the "nightly" GitHub release (MyApp-Setup-x64.exe)
Computer: a Windows cloud computer. Uninstall any older version first.
Test account: qa-desktop@example.com (send me an approval link to sign in; don't ask for the password in chat)
Test file: sample-project.myapp from the same release

Run these flows and record pass or fail, a screenshot and how long each step took:
1. Install and first launch: the installer finishes, the app opens, no error dialogs.
2. Sign in with the test account and check the account name in the top-right corner.
3. File > Open the test file. Check the title bar and that all 3 tabs load.
4. Edit the project name, File > Save, then Save As "copy-test" in Documents. Check both files exist with the right extension.
5. Settings: switch to dark theme and a different language, restart the app, and check both settings stuck.
6. Close with unsaved changes and check the "Save changes?" prompt appears.

Only use the test account and test file. Don't change system settings outside the app.

When you finish, give me a results table and exact steps to reproduce each failure, with screenshots. Ask me before you open a GitHub issue.

Watch it run

What Sai does with this prompt

Desktop app testing means installing the real build and using it the way a person would: launch, sign in, open a file, save, change settings. Browser tools cannot reach native windows, and desktop drivers take setup. From Claude Code, you can ask Sai to run those flows on a Windows or Linux cloud computer and send back failures with screenshots.

What desktop app testing covers

Desktop app testing checks a packaged application on a real operating system: that it installs, starts, accepts input, reads and writes files, keeps settings and closes cleanly. It covers the native parts of the app, such as menus, file dialogs and system prompts, that unit tests and web tests do not reach.

Many bugs only appear in the packaged build. The installer misses a file, a path differs on a clean machine, or a native dialog behaves differently than a mock.

Why automated desktop application testing is hard

  • Browser tools stop at the window frame. Selenium drives browsers. Playwright has experimental support for Electron, but not for WPF, Qt or other native apps.
  • Each framework needs its own driver. WinAppDriver and the Appium Windows driver cover UWP, WinForms, WPF and Win32 apps. pywinauto's UI Automation backend adds Qt5. Tauri has its own WebDriver setup.
  • The driver itself needs care. The Appium Windows driver proxies to WinAppDriver, which its README says Microsoft has not maintained for years. Both need Windows 10 with Developer Mode on.
  • Scripts depend on automation IDs. Controls without stable IDs or names make scripts brittle, and custom-drawn controls may expose none at all.
  • Linux is a separate problem. pywinauto lists Linux support only as a long-term plan, so Windows scripts rarely carry over.

What to test in a desktop app before release

Use this list with any tool, scripted or not:

  1. Install and uninstall: on a clean machine, over an older version, and removal leaves no broken shortcuts.
  2. First launch: no error dialogs, the window opens at a sensible size, and first-run screens work.
  3. Sign-in: with a test account, including a wrong password and sign-out.
  4. Open and save: through the native file dialogs, with Save As, the right extension and an unsaved-changes prompt.
  5. Settings: changes survive a restart, including theme and language.
  6. Updates: the app updates from the previous release and keeps user data.
  7. Each target OS: at least one Windows and one Linux run if you ship both.

Desktop app testing tools, compared

ApproachSetupFrameworksWhen the UI changesBest for
Manual QAA test machine and a personAnyNo change neededRelease checks on a small app
WinAppDriver or Appium Windows driverWindows 10, Developer Mode, test codeUWP, WinForms, WPF, Win32Update locatorsExisting Selenium-style suites on Windows
pywinautoPython scripts on WindowsWin32 apps; WinForms, WPF and Qt5 through UI AutomationUpdate control lookupsPython teams automating Windows apps
SquishLicensed tool, recorded or scripted testsQt, Java, Windows, macOS, web, Tk and moreUpdate the object mapLarge Qt or multi-toolkit suites in CI
Playwright (Electron) or Tauri WebDriverTest code against the app's web viewElectron (experimental) or TauriUpdate selectorsFast checks of the web layer on every commit
SaiA plain-English promptAny app a person can use on Windows or LinuxWorks from what is on screenFull flows on the packaged build, after agent-written changes

If you need hundreds of fast, deterministic checks on every commit, a scripted suite with WinAppDriver, pywinauto or Squish is the better fit. Use Sai for full flows on the installed build and for the paths nobody has scripted yet.

How to test a desktop app from Claude Code with Sai

  1. Add the Sai MCP server. Add @simular-ai/sai-mcp to Claude Code. Codex and Cursor work the same way.
  2. Point to the build. Give a release or artifact link to the installer or package, and say Windows or Linux. The free plan includes one pooled Windows cloud computer; paid plans add dedicated Windows or Linux ones.
  3. List the flows. Launch, sign in, open, save, settings, or whatever matters for this change. The full prompt is in the Start with a prompt tab above.
  4. Watch and approve. Claude Code shows a watch_url link with the live screen and Sai's steps. Sign-ins and other sensitive steps wait for your approval there.
  5. Close the loop. Claude Code reads the report, writes the fix, rebuilds, and asks Sai to run the failed flow again.

Sai ranks #1 on OSWorld, the public benchmark for agents that complete tasks on a real computer, including desktop apps. Once Sai completes a task, its steps are kept as code that replays the same way, so the next run of the same flows is faster and more consistent.

From your coding agent: the loop above runs inside Claude Code through the MCP server. From CI or your own scripts, call POST /v1/agents/message with the same prompt, or use the Python SDK (pip install sai-sdk, alpha). Read the quick start.

Tips for reliable desktop test runs

  • Use a test account. Never a real customer or admin account. Sai gets the password through an approval link, not the chat.
  • Ship a test file with the build. A known sample file makes open and save checks repeatable.
  • Say what "pass" looks like. "The title bar shows the file name" is checkable; "it works" is not.
  • Start clean. Ask Sai to remove older versions first, so you test a fresh install.
  • Keep scope tight. Tell Sai not to change system settings outside the app.

Related use cases: test your signup flow end to end and reproduce a bug report step by step.

Last reviewed October 13, 2026.

Frequently asked questions

What is desktop app testing?

It checks a packaged application on a real operating system: install, launch, sign-in, opening and saving files, settings and shutdown, including native menus and dialogs that web and unit tests do not reach.

Can I test a desktop app with Claude Code?

Yes. Add the Sai MCP server to Claude Code and ask it to have Sai install your build on a cloud computer and run the flows you list. Claude Code reads the report, writes fixes and asks Sai to re-run.

Can Playwright or Selenium test desktop apps?

Selenium drives browsers. Playwright has experimental support for Electron apps, but not for WPF, Qt or other native apps. For those you need a desktop driver or a computer-use agent.

What are the options for automated desktop application testing on Windows?

WinAppDriver and the Appium Windows driver cover UWP, WinForms, WPF and Win32 apps. pywinauto automates Windows apps from Python. Squish is a licensed tool with strong Qt support. Sai runs flows from a plain-English prompt.

Is WinAppDriver still maintained?

The Appium Windows driver README says Microsoft has not maintained the WinAppDriver server for years. It still works on Windows 10 with Developer Mode on, and Appium suggests NovaWindows Driver as an alternative.

Can Sai test Linux desktop apps?

Yes, on a dedicated Linux cloud computer, which comes with paid plans. The free plan includes one pooled Windows cloud computer.

How do I watch a desktop test while it runs?

With the MCP server, Claude Code shows a watch_url link to a live view of the cloud computer and Sai's steps. You can answer approvals, such as a sign-in, from the same view.

Does Sai replace scripted desktop app testing?

No. Keep unit tests and scripted UI tests for fast checks on every commit. Use Sai for full flows on the installed build and for paths nobody has scripted.

Test the app your users actually install

Ask from Claude Code. Sai installs the build, runs the flows on a real desktop and reports back with screenshots.