Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2) by jack-champagne · Pull Request #235 · harmoniqs/amicode

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne · 2026-07-29T15:45:36Z

Stacked on #234 — retarget this base to main before merging #234 (see warning at the bottom).

VS Code Remote-Containers installs the extension inside the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native linux-arm64 binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing to install.

This ships as part of 0.1.2, not a follow-up 0.1.3

No v0.1.2 tag or release exists yet, so the version is still open. That matters because #234 establishes that a version's target set is fixed at publish time: publish 0.1.2 without linux-arm64 and arm64 Linux clients resolve down to the stale 0.0.2 universal, with no way to retrofit the target into that published version. Landing both PRs under one v0.1.2 tag means a single Marketplace version covering every target, and no stale window.

linux-arm64 is a real target, not a cover — there is a working binary for it, so it should run, not display advice.

Changes

fork (ci(amicode): build and release a linux-arm64 binary opencode#101, released as v1.17.3-amicode.13): opencode-linux-arm64 added to the release build. It was already a valid target in script/build.ts; bun cross-compiles it from the x64 runner the same way darwin-arm64 is built.
opencode.lock.json pinned to amicode.13, now with three platforms
SUPPORTED gains linux-arm64 and is exported, so a new test asserts it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch (or advertises a platform with nothing to vendor)
release.yml: seven vsixes — four installable (universal + 3 lean) as Release assets, three covers. Marketplace publish goes to six platform entries. The pairwise mv shuffle became a loop since it no longer generalizes to three.
ci.yml: fetch + gate-check all three binaries
boot-smoke now runs on ubuntu-24.04-arm — free for public repos, and the only place a linux-arm64 binary is ever executed. The fork cross-compiles it, so this job is its native smoke test (boot_smoke.mjs boots the server and probes /event).

Verified

boot-smoke (ubuntu-24.04-arm)green — the cross-compiled binary boots and serves SSE on real aarch64
file on the vendored binary: ELF 64-bit LSB executable, ARM aarch64, sha256-verified against the lock
814/814 tests, typecheck clean
three-way mv shuffle dry-run: exactly one platform present per vsce package call, all restored

⚠️ Merge order

Do not merge #234 with --delete-branch while this PR points at it — that auto-closes this PR. Retarget this one to main first, then merge both.

A missing target platform is not neutral on the VS Code Marketplace: a client whose target has no entry resolves down to the newest *universal* version on the listing and installs it silently. Ours is 0.0.2, published before the platform split, so from 0.0.3 through 0.1.1 every Windows and Intel-Mac install landed on a stale build reporting itself as the latest version. Publish binary-less cover packages for win32-x64, win32-arm64 and darwin-x64 (2.5MB each, vs ~100MB for the universal fat vsix) so those clients resolve to the current version, and give them somewhere to go: unsupportedHostAdvice() points Windows at WSL, with a "Reopen in WSL" action when the WSL extension is present to provide the command. Fail the build if a cover package ships a binary. Windows is served by amicode-linux-x64.vsix inside the WSL host, never by win32-*; declare extensionKind: ["workspace"] so that placement is explicit rather than inferred. Document the install story in the README, which had none.

VS Code Remote-Containers installs the extension INSIDE the container, so an arm64 devcontainer (the common case on Apple Silicon) needs a native binary. We only vendored linux-x64 and darwin-arm64, so those users had nothing. - opencode.lock.json gains linux-arm64 (sha pinned from the fork release) - SUPPORTED gains linux-arm64, and is now exported so a test can assert it matches the lock exactly — the two live in different files and drifting either way ships a binary the extension refuses to launch - ci.yml + release.yml fetch and gate-check all three binaries; release.yml packages a third lean vsix and publishes it to the Marketplace - boot-smoke runs on ubuntu-24.04-arm, which is free for public repos and is the only place a linux-arm64 binary gets executed (the fork cross-compiles it, so this is its native smoke test)

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

jack-champagne added 2 commits July 29, 2026 11:27

jack-champagne force-pushed the feat/linux-arm64 branch from 545fe8a to 4c7d187Compare July 29, 2026 15:48

jack-champagne changed the title ~~Ship a linux-arm64 build for arm64 devcontainers~~Ship a linux-arm64 build for arm64 devcontainers (rides in 0.1.2)Jul 29, 2026

jack-champagne changed the base branch from fix/win32-marketplace-fallback to mainJuly 29, 2026 15:52

jack-champagne merged commit 7cc9ba7 into mainJul 29, 2026
6 checks passed

jack-champagne deleted the feat/linux-arm64 branch July 29, 2026 15:52

Uh oh!

Conversation

jack-champagne commented Jul 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This ships as part of 0.1.2, not a follow-up 0.1.3

Changes

Verified

⚠️ Merge order

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jack-champagne commented Jul 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This ships as part of 0.1.2, not a follow-up 0.1.3

Changes

Verified

⚠️ Merge order

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jack-champagne commented Jul 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This ships as part of 0.1.2, not a follow-up 0.1.3

Changes

Verified

⚠️ Merge order

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jack-champagne commented Jul 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This ships as part of 0.1.2, not a follow-up 0.1.3

Changes

Verified

⚠️ Merge order

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jack-champagne commented Jul 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This ships as part of 0.1.2, not a follow-up 0.1.3

Changes

Verified

⚠️ Merge order

jack-champagne commented Jul 29, 2026•
edited
Loading

jack-champagne commented Jul 29, 2026•
edited
Loading

jack-champagne commented Jul 29, 2026•
edited
Loading

jack-champagne commented Jul 29, 2026•
edited
Loading

jack-champagne commented Jul 29, 2026•
edited
Loading

jack-champagne commented Jul 29, 2026•
edited
Loading

jack-champagne commented Jul 29, 2026•
edited
Loading