fix(brew): handle root-owned config dir from sudo installs

[BYK]

Problem

Two errors were reported during Homebrew post-install of v0.12.0:

1. SQLiteError: unable to open database file (SQLITE_CANTOPEN) — setup aborts
2. Warning: read-only database + EPERM on zsh completions — setup aborts

Root cause: sudo brew install creates root-owned ~/.sentry/ and ~/.local/share/zsh/ files. The setup command had no error handling, so any failure aborted the entire post-install script and Homebrew showed a scary error even though the binary installed fine.

The same root cause explains the recurring "attempt to write a readonly database" Sentry telemetry issues (8 issues, 19 events, 100% macOS). Moving the config directory would not help — the same permission problems would occur at any path if created by root. macOS TCC does not restrict ~/.sentry/.

Changes

Non-fatal setup steps (setup.ts)

Added a bestEffort() wrapper around each post-install configuration step. Permission failures now log a warning instead of aborting. The binary is already installed — these steps are nice-to-have side effects.

Root-owned file detection in tryRepairReadonly (telemetry.ts)

Before attempting chmod (which fails silently on root-owned files), now checks stat().uid. If the file is owned by root, emits a targeted actionable message with the actual username:

Warning: Sentry CLI config directory is owned by root.
  Path:  /Users/am/.sentry
  Fix:   sudo chown -R am "/Users/am/.sentry"
  Or:    sudo sentry cli fix

Username is inferred from SUDO_USER → USER → USERNAME → os.userInfo().

Ownership repair in sentry cli fix (fix.ts)

• Ownership check runs before permissions (chmod fails on root-owned files anyway)
• Not root: prints sudo chown -R <user> <configDir> and sudo sentry cli fix instructions, exits with code 1
• Running as root (sudo sentry cli fix): resolves the real user's UID via id -u <username>, then performs chown to transfer ownership back

Fixes CLI-7Q, CLI-7K, CLI-6N, CLI-6D, CLI-4Z, CLI-51, CLI-4E, CLI-2E

[github-actions]

Semver Impact of This PR

🟢 Patch (bug fixes)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

Bug Fixes 🐛

• (brew) Handle root-owned config dir from sudo installs by BYK in #288

• (setup) Show actual shell name instead of "unknown" for unsupported shells by BYK in #287

Internal Changes 🔧

• Only showing status about changed files in codecov by MathurAditya724 in #286

---

_{🤖 This preview updates automatically when you update the PR.}

[github-actions]

Codecov Results 📊

❌ Patch coverage is 78.31%. Project has 3639 uncovered lines.
❌ Project coverage is 75.35%. Comparing base (base) to head (head).

Files with missing lines (3)

File	Patch %	Lines
fix.ts	80.65%	⚠️ 77 Missing
telemetry.ts	90.75%	⚠️ 38 Missing
setup.ts	98.08%	⚠️ 5 Missing

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
- Coverage    75.38%    75.35%    -0.03%
==========================================
  Files          115       115         —
  Lines        14518     14760      +242
  Branches         0         0         —
==========================================
+ Hits         10943     11121      +178
- Misses        3575      3639       +64
- Partials         0         0         —

---

Generated by Codecov Action

[BYK]

Addressed both review comments in b965269:

Promise.allSettled in checkOwnership: Refactored to use Promise.allSettled — stat all 4 paths in parallel, then iterate the settled results. Fulfilled results with a foreign uid become ownership issues; rejected results with ENOENT/EACCES are silently skipped; any other rejection is re-thrown. Removes the nested async try/catch in favour of a cleaner loop.

Bun.$ in resolveUid: Replaced with execSync from node:child_process (same pattern already used in the Bun.which polyfill). This works on both the Bun binary and the npm/node distribution with no shim needed. Also simplified resolveUid from async to sync since execSync is blocking.

[BYK]

Addressed all four review comments in c4d7ea1:

Command injection in resolveUid (Seer + Cursor BugBot — high): Replaced execSync(id -u ${username}) with execFileSync("id", ["-u", "--", username]). execFileSync bypasses the shell entirely — the username is passed as a discrete argument, so no metacharacters can escape. The -- separator also guards against usernames starting with -.

Ownership check wrong when running as sudo (Cursor BugBot — high): Real bug. When sudo sentry cli fix runs, process.getuid() returns 0, and files from sudo brew install are also uid 0 — so the mismatch check always passed. Fix: handleOwnershipIssues now resolves the real user's UID via resolveUid(getRealUsername()) before calling checkOwnership, and passes that as the comparison UID instead of the process UID. If resolveUid returns null (unknown user), we fall back to 0 and still detect the mismatch correctly.

Duplicated getRealUsername (Cursor BugBot — low): Moved to src/lib/utils.ts and imported in both fix.ts and telemetry.ts. Single source of truth.

[BYK]

Addressed two more comments in 2a41fca:

fix can chown files to root (Cursor BugBot — high): Added an explicit guard: if resolveUid(username) returns 0 (e.g. when getRealUsername() resolves to "root" because no SUDO_USER/USER env var is set and userInfo().username is "root"), we now refuse to chown and print manual instructions instead. Chowning to uid 0 would worsen the situation, not fix it.

getRealUsername may throw (Cursor BugBot — medium): Wrapped userInfo() in a try/catch in src/lib/utils.ts. If it throws (e.g. corrupted passwd entry), the call silently yields ""\ and the fallback chain continues to $(whoami)`.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[BYK]

Addressed two more comments in 620f800:

fix can chown files to root (Seer — critical): The previous fallback comparisonUid = targetUid ?? currentUid was wrong: when resolveUid returns null and currentUid === 0, comparisonUid became 0, making root-owned files look correctly-owned. Fixed by bailing early (before calling checkOwnership) when we can't resolve a non-root UID — we print manual instructions and return. This also removes the later redundant null/0 check since it's now impossible to reach the chown code without a valid non-root resolvedUid.

isOwnedByRoot always returns true on Windows (Cursor BugBot — medium): fs.stat().uid always returns 0 on Windows regardless of actual ownership. Added an early process.platform === "win32" guard that returns false immediately, matching the behavior of the fix command itself (which skips ownership checks on Windows via process.getuid() returning undefined).