[Bug]: Homebrew-distributed app fails to detect Claude Code (and Codex) provider — works fine when built from source

[jonathanperis]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Install T3 Code via Homebrew (v0.0.15 Alpha, installed as a macOS .app bundle).
2. Ensure Claude Code CLI is installed and fully authenticated — claude --version returns v2.1.92, /usage shows an active session, and the CLI works normally in any terminal window.
3. Ensure Codex CLI is similarly installed and available on PATH in a terminal.
4. Launch T3 Code from the Applications folder (i.e. as a GUI app, not from the terminal).
5. Open Settings → Providers.
6. Observe the status message for both the Codex and Claude Code providers.

Expected behavior

Both providers should detect their respective CLIs, confirm authentication, and become ready to use — matching the behavior seen when the app is run locally via bun dev or bun start from a terminal.

Actual behavior

Both providers are perpetually stuck on:

"Checking provider status — Waiting for the server to report installation and authentication details."

Neither provider ever transitions to a ready or authenticated state. The Settings page shows no error — just an indefinite spinner/pending message for both Codex and Claude Code.

Notably, cloning the repo and running the app from source (via a terminal) works perfectly: providers are detected and authenticated immediately.

Key contrast: Homebrew bundle vs. built from source

Launch method	Provider detection
Homebrew .app (from Applications)	Stuck on "Checking provider status…"
bun dev / built from source (via terminal)	Works immediately

This strongly suggests the Homebrew-distributed .app bundle does not inherit the user's login shell PATH (where claude and codex are installed), while running from a terminal naturally has the correct PATH already set.

Hypothesis / suspected root cause

macOS GUI applications launched from Finder or the Dock do not source the user's shell profile (~/.zshrc, ~/.zprofile, etc.). The bundled app must explicitly probe the login shell to reconstruct PATH. If that probe fails or produces an incomplete PATH, neither claude nor codex will be found — even though they are perfectly accessible in any terminal.

This is the same root-cause class as:

• macOS desktop app fails to detect Codex when login shell is Nushell #309 — app fails to detect Codex when login shell is Nushell (POSIX probe args are invalid for non-POSIX shells)
• [Bug]: macOS login shell sync misses Homebrew and other env vars, causing terminal command errors #1465 — readEnvironmentFromLoginShell copies only PATH, missing HOMEBREW_PREFIX and other env vars set in ~/.zprofile

The claude CLI is typically installed by the Claude Code installer into a non-standard location (e.g. ~/.claude/local/claude, or via a shell shim under ~/.local/bin) that is added to PATH only via shell profile scripts. If readPathFromLoginShell / readEnvironmentFromLoginShell fails for any reason — shell probe timeout, non-POSIX shell, or simply not capturing the right profile — the binary is invisible to the app process.

Impact

Blocks work completely

Version or commit

0.0.15

Environment

• Machine: Mac Mini M1, 16 GB RAM
• OS: macOS Tahoe 26.3.1 (a) (Darwin arm64)
• Install method: Homebrew cask (.app bundle)
• App version: 0.0.15 Alpha (shown as "Up to Date" in-app)
• Claude Code CLI: v2.1.92, authenticated, Claude Max plan active (/usage confirms current session active, 6% used)
• Subscription: Claude Max

Logs or stack traces

# No error logs visible in the app UI.
# Both providers show indefinite pending state.
# Claude Code CLI in terminal works normally:
$ claude --version
# Claude Code 2.1.92
$ claude /usage
# (shows active session, current period usage ~6%)

Screenshots, recordings, or supporting files

The Settings page shows both the Codex and Claude Code providers stuck on "Checking provider status — Waiting for the server to report installation and authentication details." Side-by-side with a Claude Code terminal session showing v2.1.92 authenticated and /usage reporting active usage. (Screenshot available on request — not attached as it contains a local file path.)

Workaround

Running the app from source via a terminal (clone repo → bun install → bun dev) works correctly because the terminal process already has the correct PATH from the shell profile. No known workaround for the Homebrew-distributed binary.