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

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)

Start with util/generic/architecture.go and command/common/install_plugin_command.go, then trace through actor/pluginaction.Actor.GetPlatformString. Compare that path with actors/plugininstaller/plugin_downloader.go and its downloadFromPlugin function, reproducing on macOS arm64 with the supplied plugin example. Done means arm64 platform selection and the legacy path are covered without regressing existing macOS plugin installs, with the related cli-plugin-repo platform documentation coordinated.