You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: macOS desktop never refreshes the login-shell environment after launch — tools installed later (Homebrew, gh, opencode, nvm node) stay invisible to agents and VCS #9429
Launch the packaged T3 Code app from Finder on a fresh macOS user that has no Homebrew yet.
While the app is running, install Homebrew (/opt/homebrew), which appends eval "$(/opt/homebrew/bin/brew shellenv zsh)" to ~/.zprofile. Install gh with brew and authenticate it.
Also install a tool that only lands on PATH through ~/.zshrc (opencode in ~/.opencode/bin, or node via nvm).
In an agent thread (Claude Code adapter) run which brew gh opencode node, and open Settings → Source Control.
Expected behavior
After the shell profiles change, the app should re-capture the login-shell environment (at least on "Rescan server environment", ideally periodically or on profile mtime change) so that brew, gh, opencode, node resolve exactly like they do in Terminal.app.
Actual behavior
The desktop process keeps the PATH captured at launch and never probes again. Every later spawn of a bare tool name fails with ENOENT, even though the same commands work in Terminal.
12 × spawn codex ENOENT from probeCodexAppServerProvider (before codex was installed, expected)
launchctl getenv PATH is empty on macOS 26, so there is no system-level fallback. opt/homebrew appears 0 times in the trace logs.
Impact
Major degradation or frequent failure
Version or commit
0.0.38 (packaged desktop app, com.t3tools.t3code)
Environment
macOS 26.6.2 (25G83), Apple Silicon (arm64), login shell /bin/zsh, Homebrew at /opt/homebrew, gh via Homebrew, node via nvm, opencode in ~/.opencode/bin, Claude Code adapter.
Quit and relaunch T3 Code after installing tools or editing shell profiles. Inside an agent thread, prefix commands with eval "$(/opt/homebrew/bin/brew shellenv zsh)" or use absolute paths.
Confirmed in source. The login shell probe runs exactly once, at desktop bootstrap: shellEnvironment.installIntoProcess in apps/desktop/src/app/DesktopApp.ts captures the shell env into the main process, the bundled server inherits it on spawn, and nothing ever re-captures it. The "Rescan server environment" button only calls discovery.refresh(), which re-runs the probes inside the server process, so it rechecks the same stale PATH it inherited at launch. That lines up with your 122 ENOENT gh spawns after installing brew. Worth noting for whoever picks this up: re-probing on rescan is the easy half, but the running server child can't have its env changed from outside, so the fresh PATH also needs a path into the server (control channel or a runner restart) before tool spawns see it.
Activity
Mnigos commentedon Sep 4, 2026
Confirmed in source. The login shell probe runs exactly once, at desktop bootstrap:
shellEnvironment.installIntoProcessinapps/desktop/src/app/DesktopApp.tscaptures the shell env into the main process, the bundled server inherits it on spawn, and nothing ever re-captures it. The "Rescan server environment" button only callsdiscovery.refresh(), which re-runs the probes inside the server process, so it rechecks the same stale PATH it inherited at launch. That lines up with your 122 ENOENT gh spawns after installing brew. Worth noting for whoever picks this up: re-probing on rescan is the easy half, but the running server child can't have its env changed from outside, so the fresh PATH also needs a path into the server (control channel or a runner restart) before tool spawns see it.