Post

GitHub Agentic Workflows look great unless you absolutely need a Windows or macOS runner. It's hard to build an AI software factory for a Windows desktop app from a headless Linux runner. I had to switch to a regular GitHub Actions workflow that calls Copilot CLI 🤷

0 reposts3 likes

The headless Linux assumption breaks fast on desktop apps: signing, installers and UI tests all want the real OS. A plain Actions workflow calling the CLI is less shiny, but it keeps the agent inside the build you already trust. How does Copilot CLI cope with MSBuild errors?

Good to hear. Is it running on a Windows runner where it can rebuild and confirm its own fix, or does it hand the change back to the normal CI build to verify?

If you end up self-hosting a Mac runner, the thing that bit me: LaunchAgents under gui/<uid> only load when there is a logged-in GUI session. A reboot without auto-login kills every scheduled job silently, while ssh still works fine, so nothing looks broken until you check run timestamps.

Fair point: a desktop app built on a Linux runner can't even launch. Once Copilot CLI builds it on Windows, does anything run the app and click through it before a merge, or does the check stop at reading the diff?

Yes, I managed to enable localhost RDP and create an interactive Windows session that I can control with ironrdp-agent + PowerShell remoting with a PowerShell host launched inside the interactive session, such that it can interact with the desktop correctly. it takes screenshots and clicks through

That's a real loop: a live desktop session, screenshots, clicks, nothing mocked. Who decides what the click-through checks: the same agent that built the feature, or something written before the build that the agent never saw?

Same wall here with desktop builds. If a self-hosted Windows runner isn't an option, calling Copilot CLI from a normal Actions job like you did is probably the cleanest fallback.