Reproduction: desktop login-shell PATH timeout

Environment: Linux x86_64 VM, Electron 44.10.1, headless-desktop/Xvfb at 1920x1080, light theme. This exercises the shared POSIX desktop shell path, not native macOS.

Each checkout was installed with vp i and built with vp run build:desktop:bundle. That supported target omits the unrelated native Linux browser-import secret helper. Electron's runtime was installed with node node_modules/electron/install.js from apps/desktop.

Run the uploaded driver as:
  headless-desktop python3 run.py <checkout> <side>

The driver creates a fresh synthetic HOME and T3CODE_HOME. Its .bash_profile sleeps 7 seconds and then prepends $HOME/tools to PATH. A stub codex is executable there, reports version 0.156.1, and deliberately exits for app-server. Electron starts with only PATH=/usr/bin:/bin, SHELL=/bin/bash, the fixture home, isolated T3 state, and the display/session variables needed by headless-desktop. No live database or provider account is used.

The same timed UI sequence runs on both sides: at 25 seconds click Start without an agent; at 28 seconds open Settings with Ctrl+,; at 31 seconds click Providers; at 35 seconds click Refresh provider status. Record until 55 seconds, then capture two stills 500ms apart and check byte equality.

The recordings and stills mask the environment identity in the onboarding subtitle, window title, and settings environment selector. No behavior/status text is masked. Runtime JSON files contain selected real trace spans, sanitized fixture paths, profile/codex invocation logs, the shell cache, and provider status. Initial /proc/environ is explicitly not treated as the current process.env after the desktop sends a shell update.

Interpretation: the base records the 5-second timeout span as Success and never invokes the fixture CLI, including after Refresh. The head records the first timeout as Failure, retries with the longer budget, captures the shell PATH, and invokes the fixture CLI on Refresh. Its later transport error is intentional stub behavior, not an executable-not-found failure. The initial provider status can remain stale until refreshed; no claim of immediate automatic provider status recovery is made.

AI-assisted; verified with the tests and tools listed above.