[Bug]: macOS 0.1.3 cannot find claude or gh although both resolve in the shell #26372

Area

apps/desktop (possibly server environment / executable discovery)

Observed behavior

T3 Code cannot find either claude or gh on PATH on my Mac. For comparison, Codex and Claude Code have no issues on the same machine.

The executable checks below also succeed from the shell used by the Codex agent running inside T3. This suggests a difference between T3's own executable discovery environment and the agent's shell environment, but the effective PATH of the failing T3 process has not been captured, so the root cause is not confirmed.

Steps to reproduce / affected setup

This is an observation from an affected installation, not a deterministic clean-machine reproduction:

1. Use T3 Code desktop 0.1.3 on Apple Silicon macOS, with zsh as the user shell.
2. Have GitHub CLI installed at /opt/homebrew/bin/gh and Claude Code installed at ~/.local/bin/claude.
3. Try to use Claude and GitHub CLI integration in T3. T3 reports that it cannot find the executables, while shell invocations succeed.

Expected behavior

T3 discovers and runs the installed Claude Code and GitHub CLI executables using the user's configured PATH, consistently with Codex and Claude Code on the same machine.

Actual behavior

T3 cannot find either executable. The exact UI error wording and failing process PATH have not been captured.

Impact

Major degradation: Claude provider and GitHub CLI integration are unavailable despite working installations.

Version or commit

T3 Code (Beta) desktop: 0.1.3 (verified from the installed app's Info.plist).
T3 server: 0.1.3 (verified through t3_environment_read).

Environment

• macOS 26.7.1
• Apple Silicon / arm64
• Shell: zsh
• Claude Code: 2.1.312
• GitHub CLI: 2.92.0
• ~/.zprofile initializes Homebrew with eval "$(/opt/homebrew/bin/brew shellenv)".
• The agent's shell PATH includes /opt/homebrew/bin, /usr/local/bin, and ~/.local/bin.

Diagnostic evidence

After adding the symlink described below, both commands work even with a minimal explicit PATH:

env -i HOME="$HOME" PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin \
  /bin/sh -c 'command -v claude; claude --version; command -v gh; gh --version'

Output:

/opt/homebrew/bin/claude
2.1.312 (Claude Code)
/opt/homebrew/bin/gh
gh version 2.92.0 (2026-04-28)
https://github.com/cli/cli/releases/tag/v2.92.0

These checks establish that both binaries resolve and execute successfully with those PATH entries. They do not establish which PATH the failing T3 discovery process uses.

Workaround attempted

Added /opt/homebrew/bin/claude as a symlink to the existing ~/.local/bin/claude installation. Shell discovery and execution were verified afterward, but this has not been confirmed to fix T3 discovery. A full T3 restart has not been independently verified as a workaround.

Related reports

• [Bug]: macOS Source Control reports installed Homebrew gh as unavailable #7618: macOS Source Control reports installed Homebrew gh as unavailable (reported on 0.0.33).
• [Bug]: macOS login-shell PATH capture times out at 5s and is recorded as Success, so every provider reports "not found on PATH" #10534: macOS login-shell PATH timeout, referenced by [Bug]: Linux server keeps the service PATH for its whole run when the login-shell PATH read times out at startup #22336.
• [Bug]: Linux server keeps the service PATH for its whole run when the login-shell PATH read times out at startup #22336: Linux server retains service PATH after login-shell PATH hydration times out.

This may be another occurrence of the same environment-hydration problem. Linking the existing reports rather than claiming a distinct confirmed root cause. It would help to expose the effective PATH and any shell-environment hydration failure alongside executable-discovery errors.