native sessions run their shell under Rosetta, so brew misresolves arm-only formulas #1291

New issue

Closed

opened 2026-08-27 02:48:58 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-27 02:48:58 +00:00

Owner

brew upgrade aos inside a native aterm session failed with Error: coilyco-flight-deck/tap/aos: formula requires at least a URL.

The formula is fine. The session's shell runs translated, so Homebrew resolves the macOS/Intel branch, which the tap does not ship (aterm/release-targets.txt lists darwin/arm64 only).

Measured in the session shell:

sysctl -n sysctl.proc_translated -> 1
arch -> i386, while machdep.cpu.brand_string -> Apple M3 Pro
brew config -> macOS: 26.5-x86_64, CPU: 11-core 64-bit westmere, Rosetta 2: true
arch -arm64 brew config -> macOS: 26.5-arm64, Rosetta 2: false, and brew info then resolves 0.242.0 -> 0.249.0 correctly

Which ancestor introduces the translation is not established. Inspected: kitty is universal, /opt/homebrew/bin/aterm is arm64-only, and the running claude binary (~/.local/share/claude/versions/2.1.246) is arm64-only, so none of the three explains an x86_64 posture on its own. A follow-up should read the translated flag per pid rather than infer it from the binaries.

Impact is wider than brew: anything an agent runs in a native session that branches on host arch sees x86_64 on an ARM Mac. Workaround today is arch -arm64 <command>.

Second, smaller finding from the same session: aterm bundles bakes the generating shell's PATH, and a native session's PATH starts with per-session shadow entries (/tmp/aos/native/<id>/home/.local/libexec/agent-git-attribution), including other sessions' ids. livePathEntries drops only paths that do not exist at generation time, so a session shim that exists right now survives into the bundles. Generating from inside a session needs a clean PATH, or the filter needs to reject the session-shadow prefix.

`brew upgrade aos` inside a native aterm session failed with `Error: coilyco-flight-deck/tap/aos: formula requires at least a URL`. The formula is fine. The session's shell runs translated, so Homebrew resolves the macOS/Intel branch, which the tap does not ship (`aterm/release-targets.txt` lists `darwin/arm64` only). Measured in the session shell: - `sysctl -n sysctl.proc_translated` -> `1` - `arch` -> `i386`, while `machdep.cpu.brand_string` -> `Apple M3 Pro` - `brew config` -> `macOS: 26.5-x86_64`, `CPU: 11-core 64-bit westmere`, `Rosetta 2: true` - `arch -arm64 brew config` -> `macOS: 26.5-arm64`, `Rosetta 2: false`, and `brew info` then resolves `0.242.0 -> 0.249.0` correctly Which ancestor introduces the translation is not established. Inspected: kitty is universal, `/opt/homebrew/bin/aterm` is arm64-only, and the running `claude` binary (`~/.local/share/claude/versions/2.1.246`) is arm64-only, so none of the three explains an x86_64 posture on its own. A follow-up should read the translated flag per pid rather than infer it from the binaries. Impact is wider than brew: anything an agent runs in a native session that branches on host arch sees x86_64 on an ARM Mac. Workaround today is `arch -arm64 <command>`. Second, smaller finding from the same session: `aterm bundles` bakes the generating shell's PATH, and a native session's PATH starts with per-session shadow entries (`/tmp/aos/native/<id>/home/.local/libexec/agent-git-attribution`), including other sessions' ids. `livePathEntries` drops only paths that do not exist at generation time, so a session shim that exists right now survives into the bundles. Generating from inside a session needs a clean PATH, or the filter needs to reject the session-shadow prefix.

coilyco-ops referenced this issue from a commit

2026-08-27 03:54:02 +00:00

fix(aterm): name the architecture LaunchServices should launch into

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-27 03:54:03 +00:00

fix(aterm): name the architecture LaunchServices should launch into #1305

coilyco-ops closed this issue

2026-08-27 03:55:29 +00:00