[Bug] Codex setup triggers macOS malware warning and remains unavailable
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**Describe the bug**
During Buzz onboarding on an Apple Silicon Mac, setting up Codex triggered a macOS alert saying:
> “codex” was not opened because it contains malware. This action did not harm your Mac.
macOS reported that the executable was blocked and moved to Trash. Buzz then showed Codex as **Status unavailable**, including after clicking **Check Again**.
**To Reproduce:**
1. Install and open Buzz 0.4.21 on an Apple Silicon Mac.
2. In onboarding, choose Codex as a model provider.
3. Run the Codex setup flow.
4. Observe the macOS “Malware Blocked and Moved to Trash” alert for an executable named `codex`.
5. Return to Buzz and click **Check Again**.
6. Codex remains **Status unavailable**.
**Expected behavior:**
Buzz should install or detect a working Codex + ACP setup without triggering a macOS malware warning. If setup fails, the UI should identify which executable was probed and show an actionable error rather than only “Status unavailable.”
**Supporting Material**
Two screenshots were captured:
- macOS dialog: “Malware Blocked and Moved to Trash” for `codex`
- Buzz onboarding: Codex selected but showing “Status unavailable”
Diagnostics collected immediately afterward:
```text
Buzz: 0.4.21
Architecture: arm64 (M1 Pro)
Existing PATH-resolved Codex:
path: ~/.vite-plus/bin/codex
package version: 0.128.0
codex --version: ENOENT because its native vendor/codex executable is missing
Buzz setup log:
npm install --global --prefix ~/Library/Application Support/Buzz/node-tools @agentclientprotocol/codex-acp
exit: 0
codex-acp: 1.1.5
nested @openai/codex: 0.144.6
Buzz-installed native binary:
architecture: arm64
signature: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
direct --version: codex-cli 0.144.6
```
The npm install itself completed successfully. The older PATH-resolved Codex package is now missing its native executable, while the newer Codex 0.144.6 installed under Buzz still launches directly. I therefore cannot confirm from the dialog alone which `codex` path macOS moved, but it may be relevant that Buzz encountered an older, broken Codex wrapper on `PATH` while also installing a newer nested binary.
**Environment (please complete the following information):**
- OS: macOS 26.5.2 (build 25F84)
- Hardware: MacBook Pro with Apple M1 Pro
- Architecture: arm64
- Buzz version: 0.4.21
- Codex on PATH: package 0.128.0, native executable missing after the alert
- Codex installed by `codex-acp`: 0.144.6
- `codex-acp`: 1.1.5
**Additional context**
It would help if provider setup logged or displayed the exact resolved paths for both the Codex CLI and ACP adapter. That would make it clear whether Buzz is validating the existing CLI on `PATH` or the Codex binary installed with `codex-acp`.
Contributor guide
Research direction
Start with the Codex provider setup flow and the Check Again path described in the reproduction steps, then reproduce on an Apple Silicon Mac while checking the resolved CLI and ACP paths. Done means Buzz distinguishes the executable it probes, handles the malware-blocked or missing binary clearly, and reports an actionable setup result instead of only “Status unavailable.”
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100