[Bug]: macOS login-shell PATH capture times out at 5s and is recorded as Success, so every provider reports "not found on PATH"

Raised from downstream fleet tooling (new-trixie-box), found while debugging a Codex provider that would not spawn.

Area: apps/desktop

Summary

On macOS the bootstrap login-shell environment capture can time out at its 5000 ms bound against a perfectly ordinary zsh. The launchctl getenv PATH fallback is empty on a stock machine, so nothing is captured, and both parent spans still record exit: Success. The desktop process, the bundled server, and every provider spawned from it then run with launchd's default PATH (/usr/bin:/bin:/usr/sbin:/sbin) for the entire app run.

Nothing surfaces in the UI. The failure is reported to the user as a missing CLI instead.

Evidence

From ~/.t3/userdata/logs/desktop.trace.ndjson.* for a single app run (app started 15:18:40 local):

15:19:06.241  desktop.shellEnvironment.runCommandOutput          6105 ms
              DesktopShellEnvironmentCommandTimeoutError
              { "probe": "login-shell", "executable": "zsh", "argumentCount": 2, "timeoutMs": 5000 }
              "Desktop shell environment login-shell probe (zsh) timed out after 5000ms."   [WARN]
15:19:12.355  desktop.shellEnvironment.runCommandOutput           156 ms   (fallback probe, no value)
15:19:12.512  desktop.shellEnvironment.installPosixEnvironment   6270 ms   exit: Success
15:19:12.512  desktop.shellEnvironment.installIntoProcess        6270 ms   exit: Success

Effective PATH of every T3 process afterwards, via ps -wwEo command=:

/usr/bin:/bin:/usr/sbin:/sbin

The same capture run by hand on the same machine, warm, completes in about 1.1 s and returns the full PATH:

$ time /bin/zsh -ilc "printf '%s\n' '__T3CODE_ENV_PATH_START__'; printenv PATH || true; printf '%s\n' '__T3CODE_ENV_PATH_END__'"
...
1.127 total

So this is a timing failure at cold start, not a broken shell configuration. launchctl getenv PATH is empty here, and /var/db/com.apple.xpc.launchd/config/user.plist does not exist, which is the default state.

Impact

Anything spawned by a bare command name fails for the whole app run, and the app run is long: this one had been up 17 hours.

The user-visible message is misleading. The Codex provider reported:

Codex CLI (codex) was not found on PATH.

while codex 0.153.2 was installed at /opt/homebrew/bin/codex and worked in any terminal. The thread-level error was:

ProviderAdapterProcessError: Failed to spawn Codex App Server process for command: codex app-server

checkCodexProviderStatus produces that text from isCodexAppServerSpawnError, so a spawn failure caused by the app's own empty PATH is presented as a missing installation. Setting an absolute binaryPath in provider settings works around it per provider, and the probe then reports installed: true immediately.

Suggested changes

1. Do not record a swallowed capture failure as exit: Success on installPosixEnvironment and installIntoProcess. The WARN event is only reachable by reading the trace file.
2. Surface the failed capture in the UI, and distinguish it from a missing CLI. "The shell environment could not be captured" is actionable; "codex was not found on PATH" sends the user to reinstall a CLI that is already installed.
3. Retry once before giving up, or raise the bound. 5000 ms is tight for a cold start where the login shell has not been paged in yet.
4. Offer a way to re-run the capture without restarting the app.

Related, but not duplicates

• #9429 — the capture never refreshes after launch. That one starts from a capture that succeeded; this one never gets a value at all.
• #7846 — the probe is rejected at parse time by nushell. Different cause, same swallowed outcome.
• #6115, #7618 — downstream symptoms of a provider being judged missing.

Environment

• T3 Code (Alpha) 0.0.99-gitcache.1
• macOS 26.6.2 (25G83), Apple Silicon
• Login shell zsh 5.9, SHELL=/bin/zsh
• codex 0.153.2 at /opt/homebrew/bin/codex

Start in apps/desktop by tracing desktop.shellEnvironment.runCommandOutput through installPosixEnvironment and installIntoProcess, then inspect checkCodexProviderStatus and isCodexAppServerSpawnError. Use the supplied trace and cold-start zsh scenario to reproduce the timeout. Done means capture failures are surfaced distinctly from missing CLIs and the affected provider process receives the captured environment or a clear recovery path.