install-plugin silently installs x86_64 binaries on Apple Silicon (no arm64/osxarm64 platform ever requested) — downstream commands fail with zero output

util/generic/architecture.go と command/common/install_plugin_command.go から始め、actor/pluginaction.Actor.GetPlatformString まで追跡します。その経路を actors/plugininstaller/plugin_downloader.go およびその downloadFromPlugin 関数と比較し、提供された plugin の例を使って macOS arm64 で再現します。arm64 のプラットフォーム選択と legacy path がカバーされ、既存の macOS plugin のインストールをリグレッションさせず、関連する cli-plugin-repo のプラットフォームドキュメントが調整されていれば完了です。

Summary

On macOS arm64 (Apple Silicon) without Rosetta 2 installed, cf install-plugin -r <repo> <plugin> always downloads the x86_64 (osx) build of a plugin, never an arm64 one — because the CLI's plugin-platform resolution never asks for arm64 at all. If the downloaded plugin has no arm64 build reachable through the index, every subsequent invocation of that plugin's commands fails via fork/exec: bad CPU type in executable, and the CLI swallows the error completely — the command just exits 1 with no output whatsoever, making this extremely hard to diagnose.

This appears to be the still-open, still-unresolved subject of #2292 (open since 2022, last comment 2024-10-04 asking "is this blocked on cli or cli-plugin-repo?") and cloudfoundry/cli-plugin-repo#448 (open since 2023, first comment: "Depends upon the completion of cloudfoundry/cli#2292"). I'm filing this with concrete repro, exact source pointers, and evidence of real-world impact, since neither issue has that attached and both have been dormant for ~2 years.

Environment

• macOS, Apple Silicon (arm64), no Rosetta 2 installed
• Darwin 27.0.0
• cf CLI 8.19.0 (also reproduced by reading the current main branch — same code as the latest release v8.19.0 — so this is not fixed in the latest version)
• Plugin: multiapps 3.11.1 from the CF-Community repository (plugins.cloudfoundry.org)

Repro

cf install-plugin -r CF-Community multiapps -f
# ... apparently succeeds, or fails loudly with "bad CPU type in executable"
# depending on whether Rosetta happens to be present ...

cf deploy some.mtar
# exit code 1, ZERO output — no error message at all
cf mtas
# exit code 1, ZERO output

Root cause

cf install-plugin's platform resolution never considers GOARCH for macOS. Two places in cloudfoundry/cli hardcode this:

1. util/generic/architecture.go — GeneratePlatform(runtimeGOOS, runtimeGOARCH string) string, used by the current install-plugin command path (command/common/install_plugin_command.go → actor/pluginaction.Actor.GetPlatformString → this function):

   case runtimeGOOS == "darwin":
       return "osx"
   

   runtimeGOARCH is a parameter of the function but is never read in the darwin branch. It always returns "osx", whether running under amd64 or arm64.

2. The legacy path, cf/actors/plugininstaller/plugin_downloader.go's downloadFromPlugin, has the identical bug:

   arch := runtime.GOARCH
   switch runtime.GOOS {
   case "darwin":
       return downloader.downloadFromPath(downloader.getBinaryURL(plugin, "osx")), ...
   

   arch is captured but unused in the darwin case.

Neither function, nor anything else in the codebase, ever produces or looks up an osxarm64 (or any arm64-specific macOS) platform string. So no matter what a plugin's index entry contains, cf install-plugin on an Apple Silicon Mac can only ever request the osx (x86_64) binary.

Confirmed bad data this produces

Live https://plugins.cloudfoundry.org/list (fetched today) for multiapps 3.11.1 only advertises:

{
  "platform": "osx",
  "url": "https://github.com/cloudfoundry/multiapps-cli-plugin/releases/download/v3.11.1/multiapps-plugin.osx"
}

— no osxarm64 entry — even though multiapps-cli-plugin's own GitHub release for that exact tag does ship a genuine arm64 binary at:

https://github.com/cloudfoundry/multiapps-cli-plugin/releases/download/v3.11.1/multiapps-plugin.osxarm64

(verified via lipo -info / file — confirmed arm64 Mach-O). It's simply unreachable through cf install-plugin, both because the index doesn't list it under a distinct platform key and because the CLI would never ask for that key even if it did.

This isn't multiapps-specific — it's a systemic gap in the platform taxonomy

cli-plugin-repo's own contributor docs (docs/CLIPR.md) only document osx/win64/etc. as valid platform values — there has never been an arm64-macOS key in the schema. Plugin authors have worked around this inconsistently in the live index (repo-index.yml):

• SAP/cf-cli-java-plugin's only platform: osx entry actually points at a -macos-arm64 binary — works on Apple Silicon, silently broken on Intel Macs (the inverse of this bug).
• adbr-plugin lists two binaries both tagged platform: osx (amd64 first, arm64 second); since the CLI's lookup (getPluginInfoFromRepositoryForPlatform) returns the first platform == "osx" match, arm64 users always get the amd64 binary.

Fixing this only in cli-plugin-repo (adding an osxarm64 binary entry for multiapps) would not help, because cf install-plugin would still never request that platform string — the fix has to start in cloudfoundry/cli, exactly as cli-plugin-repo#448's first comment already concluded.

Why this is worse than a normal "missing binary" bug

cf install-plugin may itself report the download/exec failure loudly (see cloudfoundry/multiapps-cli-plugin#160 for that symptom), but once a bad-arch binary is on disk, every subsequent invocation of a command belonging to that plugin fails with exit code 1 and zero output — no error message, no stack trace, nothing — from cf deploy, cf mtas, etc. This makes the underlying cause essentially undiagnosable without already knowing to suspect architecture mismatch and manually running the plugin binary directly to surface fork/exec ...: bad CPU type in executable.

Confirmed workaround

Download the correct osxarm64 asset directly from the plugin's GitHub release and install from the local path:

curl -LO https://github.com/cloudfoundry/multiapps-cli-plugin/releases/download/v3.11.1/multiapps-plugin.osxarm64
cf install-plugin ./multiapps-plugin.osxarm64

This resolves the issue completely (cf mtas etc. then exit 0).

Suggested fix

• Add an arm64 branch to util/generic.GeneratePlatform (and the legacy plugin_downloader.go darwin case) that requests a distinct platform string (e.g. osxarm64) when runtime.GOARCH == "arm64", falling back to osx if no arm64 binary is listed for a given plugin (to avoid breaking plugins that haven't published one yet).
• Coordinate with cli-plugin-repo (#448) to formalize osxarm64 as a documented, distinct platform key, and encourage existing plugin authors (multiapps already has the asset — this is a one-line repo-index.yml PR) to add it.

Related

• #2292
• cloudfoundry/cli-plugin-repo#448
• cloudfoundry/multiapps-cli-plugin#160 (same bad CPU type symptom, different diagnosis path)
• cloudfoundry/multiapps-cli-plugin#166 / #167 (arm64 binaries already added to multiapps releases, just not surfaced through the index/CLI)