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.
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.