[FEATURE]:Suport for AARCH32/ARM32

[zerolimites0001-web]

Describe the enhancement you want to request

Add support for AARCH32 / ARM32 (armv7l) — see detailed use case and proposal in comments below (Termux armv7l, Raspberry Pi 32-bit, etc.). Happy to test armv7 artifacts.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The enhancement description is too brief to be actionable. "That would be a good idea support for aarch32/arm32" doesn't explain the problem or need — please describe your use case, what you're trying to run opencode on, why ARM32 support is important, and any relevant context (e.g., specific device, OS, or workflow).

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new issue that follows our issue templates.

[zerolimites0001-web]

Hi team, revisiting #44783 — I'd like to expand on the original request for AARCH32 / ARM32 (armv7l) support with proper context:

Use case: Running opencode on 32-bit ARM devices which are still very common in low-cost environments:

• Android phones via Termux (armv7l) — e.g., Samsung Galaxy A03 (SM-A022M), Raspberry Pi 2/3 in 32-bit mode, and older Chromebooks/tablets
• Termux on Linux localhost ... armv7l with $PREFIX=/data/data/com.termux/files/usr (proot-distro Alpine) — currently no binary available, build fails due to lack of armv7 target
• CI runners and embedded boards where arm64 is not available

Why it matters:

• Large user base in emerging markets still on armv7 devices; they can't run the current arm64/amd64 releases
• GOARCH=arm + GOARM=7 cross-compile should be feasible; Node/Bun dependencies already support armv7 for many components
• Even a best-effort unofficial build or npm/go install with GOARCH=arm would unblock usage

Suggested approach:

• Add linux/arm/v7 to release matrix (goreleaser goarch: [amd64, arm64, arm] + docker platforms: linux/arm/v7)
• Document manual build: GOOS=linux GOARCH=arm GOARM=7 go build ./... / bun build --target=bun-linux-arm where applicable
• If full support is heavy, consider community tier ("experimental armv7")

Happy to test any armv7 artifact on real Termux armv7l hardware and report back. Thanks for considering!

[neheb]

The blocker isn't in this repo's build config, it's upstream in Bun.
opencode ships as a Bun-compiled binary (packages/opencode/script/build.ts:163 uses Bun.build with compile.target), and Bun's CompileTarget/Architecture only supports x64, arm64/aarch64 — there is no 32-bit ARM target. So arm32 (armv7/armhf) support has to land in Bun itself first (there's longstanding demand for it, e.g. oven-sh/bun#75 and RPi use cases). Even then you'd need:
1. Add arch: "arm" / armv7 entries to allTargets (build.ts:53) — the mechanical part, trivial.
2. The native runtime deps bundled at build time (@parcel/watcher, @ff-labs/fff-bun, @opentui/core, tree-sitter parsers) to ship arm32 prebuilds via the bun install --os="*" --cpu="*" step (build.ts:141-144). Most don't publish armhf binaries today.
So realistically: upstream Bun would need to add arm32 cross-compilation support, and the native dep chain would need armhf prebuilds. Short of that, arm64-on-arm32 won't help (Pi via 64-bit OS already works).

[neheb]

I question why this even uses typescript.

edit: if you want an agent for arm32, copilot through gh is the only thing available.