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
desktop: a timed-out shell env probe at launch leaves the whole session on the minimal PATH #62732
After a reboot, Desktop launched at login and its shell environment probe timed out. Desktop then ran the whole session with launchd's minimal environment, PATH=/usr/bin:/bin:/usr/sbin:/sbin. Every agent shell command lost Homebrew, nvm and other user paths, so gh, node and bun were "command not found" until I restarted the app. Plugins running in Desktop's main process could not find their CLIs either.
The same zsh -il -c 'env -0' takes about 2 s when the machine is idle. Under login load it took longer than the 5 s limit.
This is the V2 version of #49449, which was closed in the V1 triage. The code on dev still behaves the same way:
packages/desktop/src/main/service/shell-env.ts: when the -il probe returns ETIMEDOUT, loadShellEnv returns null right away and never tries the -l fallback.
packages/desktop/src/main/lifecycle/environment.ts: preferApplicationEnvironment copies the probed variables into process.env only when a probe succeeds, and nothing probes again later. One slow probe at launch decides the environment for the whole session, including the background service it starts.
Expected: a timeout falls back to -l, and a failed probe is retried later (for example in the background, then applied before the next service start), or at least reported in the UI. As it stands, the first sign is agents failing with "command not found".
Plugins
None needed to reproduce. Agent shell commands fail on their own.
OpenCode version
Desktop 2.2.6 (bundled CLI 2.2.6)
Steps to reproduce
Have a login shell whose interactive startup takes more than 5 s. Launching Desktop at login right after a reboot did this for me. From the source, adding sleep 6 to ~/.zshrc should trigger it on demand; I have not tested that variant.
Thanks for the detailed report. I reproduced this by running Desktop's shell-environment loader directly. I don't have macOS here, but the loader has no macOS-specific code path, and shell-env.ts is identical between v2.2.6 and the latest dev (caf8d6a55).
Setup: a login profile that adds a Homebrew-like directory to PATH, plus an interactive rc that runs sleep 6, in a launchd-like environment (PATH=/usr/bin:/bin:/usr/sbin:/sbin).
bash -l on its own finishes quickly with the extra directory on PATH, so the -l fallback would have worked.
loadShellEnv logs [server] Interactive shell env probe timed out: /bin/bash and returns null without trying -l.
After the startup merge, process.env.PATH stays /usr/bin:/bin:/usr/sbin:/sbin. preferApplicationEnvironment runs only once at startup, so nothing probes again later in the session.
Root cause: in packages/desktop/src/main/service/shell-env.ts, loadShellEnv returns null as soon as the -il probe times out. The -l fallback only runs when -il fails outright, never on a timeout, so a slow login shell at launch leaves the session on launchd's minimal PATH.
Fix is up in #62736: on timeout, fall through to the -l probe. Added a regression test that fails on the old code and passes with the fix (bun test 4/4 in packages/desktop).
Activity
opencodejr commentedon Nov 8, 2026
Thanks for the detailed report. I reproduced this by running Desktop's shell-environment loader directly. I don't have macOS here, but the loader has no macOS-specific code path, and
shell-env.tsis identical betweenv2.2.6and the latestdev(caf8d6a55).Setup: a login profile that adds a Homebrew-like directory to PATH, plus an interactive rc that runs
sleep 6, in a launchd-like environment (PATH=/usr/bin:/bin:/usr/sbin:/sbin).bash -lon its own finishes quickly with the extra directory on PATH, so the-lfallback would have worked.loadShellEnvlogs[server] Interactive shell env probe timed out: /bin/bashand returnsnullwithout trying-l.process.env.PATHstays/usr/bin:/bin:/usr/sbin:/sbin.preferApplicationEnvironmentruns only once at startup, so nothing probes again later in the session.The script below reproduces it. Related:
-lretry after a timeoutReproduction script (repro.sh)
Run it:
bash repro.shbunnysayzz commentedon Nov 8, 2026
Root cause: in
packages/desktop/src/main/service/shell-env.ts,loadShellEnvreturns null as soon as the-ilprobe times out. The-lfallback only runs when-ilfails outright, never on a timeout, so a slow login shell at launch leaves the session on launchd's minimal PATH.Fix is up in #62736: on timeout, fall through to the
-lprobe. Added a regression test that fails on the old code and passes with the fix (bun test 4/4 in packages/desktop).