Fix Codex Remote Control Connection Errors with Proxy Settings

When Your AI Tool Can’t Connect, Let It Diagnose Itself

I’ve been trying to link the ChatGPT app on my phone with Codex on my Mac. The idea was simple: let Codex keep working on code while I step away, then check progress or send new instructions from my phone. But every attempt to enable remote control failed with a red error: “Unable to enable remote control. Please try again.”

I tried the usual fixes—logging out and back in, restarting, updating the app, double-checking my account and workspace. Nothing worked. Then it hit me: if the problem is with ChatGPT/Codex itself, why not ask ChatGPT to fix its own issue?

The Setup: What I Wanted vs. What Was Happening

My goal wasn’t just syncing chats across devices. I wanted the phone to act as a remote for the desktop Codex—viewing tasks, adding instructions, and pushing forward on long-running jobs. The feature was right there in the settings, but it refused to cooperate.

I started with the phone app, going through the remote control setup. It asked me to pair with the desktop app, confirm the same workspace, and get a pairing code. But the real blocker was on the Mac side.

The Red Error: “Unable to Enable Remote Control”

On my Mac, I navigated to Settings → Connections → Control This Mac, and clicked “Allow.” Instead of a pairing flow, I got that red message. Restarting, re-logging, re-pairing—none of it helped.

I updated Codex from version 26.803.61601 to 26.810.50856, thinking it might be a bug. Still the same error. So version wasn’t the culprit.

Digging into Logs: The Clue That Changed Everything

We decided to check the official logs. Codex stores them in ~/Library/Logs/com.openai.codex/YYYY/MM/DD. Searching for remote control entries, I found something odd:

method=remoteControl/enable errorCode=null refresh_remote_control_started refresh_remote_control_completed nextConnectionCount=0 previousConnectionCount=0 creationFailureCount=0

The error code was null, and the module seemed to start fine, but the connection count stayed at zero. That meant the problem wasn’t the toggle itself—it was likely deeper in the network path.

Testing the Proxy: Direct vs. Explicit

My Mac requires a local proxy to reach ChatGPT. The system proxy was set to 127.0.0.1:33210 for HTTP/HTTPS and 127.0.0.1:33211 for SOCKS. Both were active, and I could use ChatGPT and Codex normally—so why would remote control fail?

We ran two quick tests. First, a direct curl to chatgpt.com without any proxy:

curl -I --connect-timeout 10 https://chatgpt.com

It timed out. Then with the proxy specified:

curl -I --proxy http://127.0.0.1:33210 --connect-timeout 10 https://chatgpt.com

That returned HTTP/1.1 200 Connection established instantly. The conclusion was clear: the main Codex app was using the proxy fine, but the remote control background connection wasn’t inheriting it.

The Fix: Injecting Proxy Variables into Codex

To verify, I quit Codex completely and relaunched it from the terminal with the proxy environment variables set:

export HTTP_PROXY=http://127.0.0.1:33210
export HTTPS_PROXY=http://127.0.0.1:33210
export ALL_PROXY=socks5://127.0.0.1:33211
open -a "Codex"

Then I tried enabling remote control again. It worked. The phone connected to my Mac instantly.

That confirmed the root cause: remote control didn’t automatically pick up the system proxy, even though the main app did.

Making It Permanent: A Dedicated Proxy Launcher

Typing those export commands every time gets old. So I built a small AppleScript app that waits 8 seconds for the proxy software to start, then launches Codex with the right environment variables. Here’s the command to generate it:

mkdir -p "$HOME/Applications"
osacompile -o "$HOME/Applications/Codex-Proxy-Launcher.app" -e 'delay 8' -e 'do shell script "export HTTP_PROXY=http://127.0.0.1:33210; export HTTPS_PROXY=http://127.0.0.1:33210; export ALL_PROXY=socks://127.0.0.1:33211; /usr/bin/open -a Codex"'

Then add that app to your login items in System Settings → General → Login Items, and remove any existing Codex auto-start entry. Also make sure your proxy software launches at login.

If your proxy ports change, just regenerate the launcher with the new ports. To undo everything, delete the login item and trash the launcher app—it doesn’t touch system network settings.

How to Know If You Have the Same Problem

Here are the signs to look for:

• ChatGPT/Codex desktop works fine, so you assume the network is OK.
• Your phone has the remote control entry, and you’re logged into the same account and workspace.
• Clicking “Allow” on the Mac always shows “Unable to enable remote control.”
• Restarting, re-pairing, or updating doesn’t help.
• You need a proxy to access ChatGPT.

If that sounds familiar, check your system proxy with scutil --proxy, then run the two curl tests. If direct fails but proxied works, you’ve found your culprit.

Why This Time It Worked: Human + AI Collaboration

What made the difference was letting ChatGPT guide the troubleshooting. It didn’t stop after a couple of generic suggestions. It kept analyzing screenshots, reading logs, and adjusting its approach. When one hypothesis failed, it moved on.

It also seemed easier for ChatGPT to debug its own ecosystem—it knew where to look in the logs and what to test. That’s a new habit I’m adopting: when an AI tool breaks, ask that tool to diagnose itself.

But the real lesson is about the collaboration. I provided the hands-on context—clicking buttons, running commands, feeding back results. The AI provided the reasoning, the documentation lookup, and the systematic narrowing. Together we pushed past the obvious and found the hidden proxy issue.

Now I can leave my Mac running Codex, step away, and still control it from my phone. That’s the kind of flexibility we all want. And it didn’t require a dedicated IT team—just a clear problem description, a willingness to test, and a patient AI partner.