Audit & remove Intel x86_64 binaries migrated to michael-air
Status Closed — not planned
Maintainer reply None cached
Activity 1 comment · opened Aug 15, 2026 · closed Aug 18, 2026
Problem
Apple's Migration Assistant blindly copied Intel (x86_64) binaries to the ARM MacBook Air (M3) without warning or info. These binaries are incompatible and cause failures — but only when you try to use them.
Related issue: #6 (michael-pro water damage / michael-air recovery)
What We've Found So Far
1. Intel Homebrew tree (/usr/local/Homebrew)
- Location:
/usr/local/Cellar,/usr/local/Caskroom,/usr/local/Homebrew - Symptom:
brewcommand fails withBad CPU type in executable - Problem: Contains Intel-only bundled Ruby; entire tree unusable
- Solution: Inventory, remove, reinstall native ARM packages under
/opt/homebrew
2. Intel login shell (/usr/local/bin/bash)
- Location: Set in
chshas login shell - Symptom: Terminal.app fails to launch; clean shells work fine
- Problem: Shell is Intel executable; Rosetta unavailable during early boot
- Solution:
chsh -s /bin/zsh(immediate); link to/opt/homebrew/bin/bashpost-Homebrew rebuild
Strategies to Find More
Strategy 1: Find all non-ARM binaries
# Find x86_64 executables in common locations
find /usr/local -type f -executable 2>/dev/null | xargs file | grep x86_64
find /opt -type f -executable 2>/dev/null | xargs file | grep x86_64
find ~/.local -type f -executable 2>/dev/null | xargs file | grep x86_64
find ~/bin -type f -executable 2>/dev/null | xargs file | grep x86_64
# Check installed binaries
file /usr/local/bin/* 2>/dev/null | grep x86_64
file /usr/local/opt/*/bin/* 2>/dev/null | grep x86_64
Strategy 2: Check PATH directories for architecture mismatches
# For each directory in PATH, check what's there
echo $PATH | tr ':' '\n' | while read dir; do
[ -d "$dir" ] && echo "=== $dir ===" && file "$dir"/* 2>/dev/null | grep -v "ASCII\|directory" | grep -c x86_64
done
# Specifically check Python/Ruby/Node paths
which python3 && file $(which python3)
which ruby && file $(which ruby)
which node && file $(which node)
Strategy 3: Check package managers
# MacPorts (if it exists)
ls -la /opt/local/bin/* 2>/dev/null | head -5 && file /opt/local/bin/* | grep x86_64
# Ruby gems
gem list --local 2>/dev/null | head
# Then check specific gems for native extensions
ls ~/.gem/ruby/*/gems/*/lib/*/x86_64* 2>/dev/null
# Python site-packages
python3 -c "import site; print(site.getsitepackages())"
find ~/.local/lib/python*/site-packages -name "*.so" -o -name "*.pyd" 2>/dev/null | xargs file | grep x86_64
Strategy 4: Check cached build artifacts
# Xcode derived data (may contain Intel builds)
du -sh ~/Library/Developer/Xcode/DerivedData
find ~/Library/Developer/Xcode/DerivedData -type f -executable | xargs file 2>/dev/null | grep x86_64
# Cargo (Rust)
ls -la ~/.cargo/bin/* | file | grep x86_64
# Go binaries
file ~/go/bin/* 2>/dev/null | grep x86_64
Strategy 5: Check system-level locations (requires sudo)
# System package managers
sudo find /Library/Caches -name "*.o" -o -name "*.a" 2>/dev/null | xargs file | grep x86_64
sudo find /var/cache -type f -executable 2>/dev/null | xargs file | grep x86_64
# Old app plugins/extensions
sudo find /Library/ScriptingAdditions -type f 2>/dev/null | xargs file | grep x86_64
sudo find /Library/InputMethods -type f 2>/dev/null | xargs file | grep x86_64
sudo find /Library/LaunchAgents /Library/LaunchDaemons -type f 2>/dev/null | xargs file | grep x86_64
Strategy 6: Check ~/Library for app-specific Intel bits
# App support bundles
find ~/Library/Application\ Support -type f -executable 2>/dev/null | xargs file | grep x86_64
# Application Scripts
find ~/Library/Application\ Scripts -type f -executable 2>/dev/null | xargs file | grep x86_64
# Caches (may contain old compiled extensions)
find ~/Library/Caches -type f -executable 2>/dev/null | xargs file | grep x86_64
Strategy 7: Check third-party app bundles
# Inside .app bundles
find /Applications -type f -executable 2>/dev/null | xargs file 2>/dev/null | grep x86_64 | head -20
Exploration Playbook
- Run Strategy 1 first — Get full inventory of x86_64 binaries
- Categorize by location —
/usr/local(Homebrew), ~/.local (user), /opt (optional), system dirs - Identify by owner — Which package manager/app installed each?
- Record before deleting — Document what was found + location
- Test each removal — Remove one category, verify system still works
- Automate post-rebuild — Once native Homebrew/Python/Node installed, generate exclusion rules for future Time Machine backups
What Should NOT Be Deleted Without Investigation
/Library/Caches— May contain compiled indexes (system-critical)/Library/Extensions— Kernel extensions (probably none on modern macOS, but check)/System/Library/*— System binaries (should never be x86_64 if Migration worked)- Third-party app bundles in
/Applications— May be universal; check before deleting
Open Questions
- How many x86_64 binaries did Apple migrate?
- Are there directories we haven't thought of?
- Should we generate a whitelist of "known-safe-to-delete" categories?
- Can we automate this detection as part of post-migration setup?
Next Steps
- [ ] Run full x86_64 audit (all strategies)
- [ ] Categorize findings by impact/regeneration cost
- [ ] Test removal of low-risk categories (Homebrew bottles cache, pip cache)
- [ ] Document safe removal order
- [ ] Add x86_64 binary search to michael-air setup checklist
- [ ] Consider automation for future ARM Mac migrations
---
This issue should stay OPEN — it's a tracking issue for the entire cleanup cycle, not a single fix.
Relates to: #6
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗