Provider maintenance subprocesses don't inherit macOS system proxy settings

I launch T3 Code from the macOS Dock. My network requires an HTTP proxy configured at the macOS system level. Notably, the Codex CLI itself seems to detect the system proxy and works fine for its runtime operations, but T3 Code's own provider update mechanism does not.

When T3 Code triggers a provider update, providerMaintenanceRunner.ts:79 spawns brew upgrade / npm install -g / opencode upgrade without any proxy context, and the command eventually times out.

DesktopShellEnvironment.ts already captures PATH, SSH_AUTH_SOCK, etc. from the login shell environment but does not retrieve macOS system proxy settings (e.g. via scutil --proxy or SystemConfiguration framework).

Not sure what the right approach is — maybe a resolveSystemProxyEnv utility in packages/shared that macOS could surface system proxy config, and then wire it through the maintenance runner. Just flagging the gap.

Start with providerMaintenanceRunner.ts:79 and DesktopShellEnvironment.ts, then inspect how the shell environment reaches brew upgrade, npm install -g, and opencode upgrade. Check the available macOS proxy sources, such as scutil --proxy or the SystemConfiguration framework, and trace the proposed packages/shared utility path. Done means provider maintenance subprocesses launched from the Dock receive the system proxy context and no longer time out behind that proxy.