Run Codex CLI Behind a Corporate Proxy While Travelling

A hotel connection, a company VPN and a corporate proxy can turn a routine coding session into a confusing chain of connection failures. The safest approach is to test each layer separately: internet access, proxy routing, certificate trust and finally the model endpoint. Follow this walkthrough before changing settings at random.

1. Confirm the approved network route

Complete the hotel or airport captive-portal login in your browser, then connect your company VPN if required. Ask IT whether command-line tools should use an explicit proxy or the VPN’s normal routing. A browser working does not prove that terminal applications have the same proxy settings.

Also confirm that company policy permits sending your repository content to your chosen AI service. A relay changes the destination of requests; it does not remove your organisation’s data-handling requirements or network restrictions.

2. Set proxy variables in one terminal

The commands below assume Bash on macOS or Linux. Replace the example address with your company’s approved proxy:

export HTTPS_PROXY=http://proxy.company.example:8080

export HTTP_PROXY="$HTTPS_PROXY"

export NO_PROXY=localhost,127.0.0.1,::1

An http:// proxy address can be correct even for HTTPS destinations: the proxy usually creates a CONNECT tunnel. Do not change it to https:// unless IT specifies that scheme. Keep these settings local to this terminal while testing, and launch Codex from the same terminal.

If your company distributes a PAC file, ask for the corresponding explicit proxy address or an approved local proxy agent. Do not assume Codex can interpret the browser’s PAC configuration. For authenticated proxies, use your company’s supported authentication mechanism rather than embedding a password in shell history.

3. Test connectivity before opening Codex

Run: curl -I --connect-timeout 15 https://api.relayvano.com

This checks basic reachability and TLS negotiation, not model access. A 404 or 405 from the destination can still mean the network path works. A 407 indicates proxy authentication is required; a certificate error points toward trust configuration. A 403 might come from the destination or a corporate filtering appliance, so inspect the response before deciding which.

A successful curl test does not guarantee that Codex uses the same networking stack. It does, however, narrow the investigation substantially.

4. Install certificate trust without disabling TLS

If your company inspects HTTPS traffic, obtain its approved CA certificate bundle from IT and follow its installation instructions for your operating system and installed Codex version. Never download a replacement certificate from an unfamiliar troubleshooting page.

Some command-line TLS stacks support SSL_CERT_FILE; curl also supports CURL_CA_BUNDLE. If IT recommends these variables, point them at an approved bundle that includes the necessary public roots as well as the corporate CA. Support varies between applications, so verify Codex separately. Do not use insecure TLS flags or disable certificate verification to make the error disappear.

5. Configure the provider and protect your key

If your organisation permits an external relay, RelayVano is a practical pay-as-you-go option for using Codex across changing networks. Its API base is https://api.relayvano.com. Before configuring it, confirm that the selected route supports the Responses API used by current Codex provider configurations; OpenAI-compatible chat endpoints alone are not sufficient.

Back up ~/.codex/config.toml. In that file, set the top-level model_provider to "relayvano" and model to the exact model identifier shown in your account. Add a [model_providers.relayvano] table containing name = "RelayVano", base_url = "https://api.relayvano.com", env_key = "RELAYVANO_API_KEY" and wire_api = "responses", with each assignment on its own line. Check the current integration instructions for any required version suffix on the base URL.

Load the key without placing its value in command history:

read -r -s -p "RelayVano API key: " RELAYVANO_API_KEY; echo; export RELAYVANO_API_KEY

6. Run a small test and clean up

Start codex in a disposable directory and request a short explanation of an empty project. Avoid sensitive files until routing, billing and authentication are confirmed. Investigate 401 errors as credentials issues, 407 as proxy authentication, and timeouts as possible routing or firewall problems.

When finished on a shared machine, unset RELAYVANO_API_KEY and remove temporary credentials. Sign up for RelayVano when you are ready to test an approved relay route, and keep a short record of the proxy and certificate settings that worked for your next trip.