[BUG]: Homebrew upgrades create stale macOS Full Disk Access entries

Description

On macOS, upgrading the Homebrew-installed opencode CLI creates another stale opencode entry under System Settings > Privacy & Security > Full Disk Access. After several upgrades, multiple old entries remain.

Current installation and signing details:

$ which -a opencode
/opt/homebrew/bin/opencode

$ ls -l "$(which opencode)"
/opt/homebrew/bin/opencode -> ../Cellar/opencode/1.18.29/bin/opencode

$ codesign -dv --verbose=4 "$(which opencode)" 2>&1
Executable=/opt/homebrew/Cellar/opencode/1.18.29/bin/opencode
Identifier=a.out
CDHash=55ac547916d866108f4e9831e58a2263da6bb2dc
Signature=adhoc
TeamIdentifier=not set

Homebrew changes the real Cellar/opencode/<version>/bin/opencode path on every upgrade. Without a stable code-signing identity, macOS TCC appears to treat each upgraded binary as a different executable and leaves the previous Full Disk Access entries behind.

Expected: upgrades preserve a stable macOS code identity so TCC recognizes the new binary as the same application and does not accumulate stale authorization entries.

Possibly related to #46313, which reports macOS release binaries failing code-sign verification.

Plugins

None relevant.

OpenCode version

1.18.29

Steps to reproduce

1. Install opencode with Homebrew on macOS.
2. Grant the CLI Full Disk Access.
3. Upgrade opencode through Homebrew several times.
4. Open System Settings > Privacy & Security > Full Disk Access.
5. Observe multiple stale opencode entries from previous versions.

Screenshot and/or share link

Operating System

macOS 26.6.2 (arm64)

Terminal

zsh