Skip to content

Engine binaries for darwin-amd64 + linux-arm64; Windows-ready engine resolution - #138

Merged
AbirAbbas merged 2 commits into
mainfrom
feat/engine-platforms
Aug 20, 2026
Merged

Engine binaries for darwin-amd64 + linux-arm64; Windows-ready engine resolution#138
AbirAbbas merged 2 commits into
mainfrom
feat/engine-platforms

Conversation

@AbirAbbas

Copy link
Copy Markdown
Collaborator

What this does

Companion to Agent-Field/agentfield#937 (desktop ships swe-planner + pr-af as bundled nodes with the Pro engine on by default). Investigating that PR showed the vendored engine set was darwin-arm64 + linux-amd64 only, so an Intel Mac or an arm64 Linux host (the platform the #937 end-to-end containers ran on) silently fell back to the classic coding loop — and the resolver could never find an engine on Windows even if one existed.

Commits

  1. fix(pro): Windows-ready engine-binary resolution. Go never reports execute bits for regular files on Windows (os.Stat yields 0666/0444), so runnable() rejected every candidate there, and siblingNames() never looked for a .exe. Both decisions are now pure, platform-parameterised helpers with table tests: on windows the candidates are swe-pro-<goos>-<goarch>.exe, swe-pro.exe, then the bare names, and an existing regular file counts as runnable; other OSes keep the execute-bit rule. Docs updated (platform set, Windows fallback, .exe lookup).
  2. feat(pro): vendor swe-pro-darwin-amd64 and swe-pro-linux-arm64. Built from the same swe-pro-go source as the existing two binaries (main @ 9c4e69a, cmd/codeaf, CGO_ENABLED=0 go build -buildvcs=false, go1.25.4 — the linux-amd64 rebuild reproduces the vendored file byte-for-byte). +55 MB in the repo; drop this commit if you'd rather not carry them.

Windows — the remaining gap

No Windows engine ships yet: swe-pro-go does not compile for GOOS=windows (internal/core/spawner.go uses Setpgid/syscall.Kill, internal/storage/storage.go and internal/modelsdev/models.go use flock). Those three need build-tagged ports before a swe-pro-windows-amd64.exe can exist; with this PR the node will pick it up the moment one lands.

Verification

  • gofmt -l ./internal/pro clean, go vet ./internal/pro/..., go test ./... in go/ all pass.
  • go version -m on the new binaries: GOOS=darwin GOARCH=amd64 / GOOS=linux GOARCH=arm64, CGO_ENABLED=0, identical dependency set to the existing binaries; swe-pro-linux-arm64 --version runs under qemu.

🤖 Generated with Claude Code

AbirAbbas and others added 2 commits August 19, 2026 15:32
…e platform set

Go never reports execute bits for regular files on Windows (os.Stat yields
0666/0444), so runnable() rejected every candidate there, and siblingNames
never looked for a .exe. The decision is now a pure, platform-parameterised
helper: on windows the candidates are swe-pro-<goos>-<goarch>.exe,
swe-pro.exe, then the bare names, and an existing regular file counts as
runnable; other OSes keep the execute-bit rule. No Windows engine ships yet
(swe-pro-go still has unix-only syscalls), so the docs say so and describe
the classic-loop fallback; they also list the vendored platform set.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Built from the same swe-pro-go source as the existing darwin-arm64 and
linux-amd64 binaries (main @ 9c4e69a, cmd/codeaf, CGO_ENABLED=0,
-buildvcs=false, go1.25.4), so an Intel Mac or an arm64 Linux host — the
platform the end-to-end containers run on — gets the engine instead of
silently falling back to the classic loop.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@AbirAbbas
AbirAbbas merged commit e8f657d into main Aug 20, 2026
3 checks passed
@habibgurdov77-star

Copy link
Copy Markdown

A

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants