Fixing Codex Remote Control: A Sailor's Guide to Taming Tech Storms

When the App Won't Connect

Ever had a tool that looks fine on the surface but refuses to do the one thing you need? That's exactly what happened with Codex Remote Control. I wanted to link my Mac's Codex to my phone so I could monitor long-running tasks from anywhere—like checking the horizon while the boat steers itself. But every time I hit "Allow," a red error popped up: "Unable to enable remote control. Please try again."

I tried the usual fixes: restarting, logging out and back in, updating the app, verifying my account and workspace. Nothing worked. Frustration mounted, and I nearly gave up, thinking it was a permissions issue or a network quirk I couldn't solve.

A New Approach: Let the AI Diagnose Itself

Then it hit me: if the problem is with ChatGPT and Codex, why not let ChatGPT figure it out? I sent screenshots of both my phone and Mac screens to ChatGPT and simply said, "Connect my desktop to my phone." That kicked off an unusual debugging session.

I did the hands-on stuff—clicking buttons, taking screenshots, running commands—while ChatGPT analyzed the visuals, read logs, consulted official docs, and proposed next steps. It wasn't a one-shot answer. We went down wrong paths, had to backtrack, but unlike earlier attempts, this wasn't a Q&A. It was a continuous loop: I provided fresh info, ChatGPT revised its hypotheses.

Narrowing It Down: Not the Obvious Suspects

We systematically ruled out the usual suspects. The workspace wasn't the issue—my phone and Mac used the same ChatGPT account and personal workspace. The app version? I upgraded from 26.803.61601 to 26.810.50856, but the red error persisted. So that was out.

The breakthrough came when we dug into the official logs. I located them at ~/Library/Logs/com.openai.codex/YYYY/MM/DD and searched for "remoteControl." The key lines showed remoteControl/enable with errorCode=null, but nextConnectionCount=0 and previousConnectionCount=0. That told us the module was starting but never establishing a connection. The problem wasn't the switch itself—it was something deeper in the network path.

The Proxy Culprit

My Mac needs a local proxy to reach ChatGPT. The main app worked fine, so I assumed the network was okay. But ChatGPT suggested a clever experiment: test direct access vs. through the proxy.

• Direct: curl -I --connect-timeout 10 https://chatgpt.com timed out.
• With proxy: curl -I --proxy http://127.0.0.1:33210 --connect-timeout 10 https://chatgpt.com returned HTTP/1.1 200 Connection established.

That was the smoking gun. The main Codex app inherited the system proxy, but the remote control background connection didn't. It was a subtle proxy inheritance issue.

Fixing It with Three Commands

The fix was surprisingly simple. I quit Codex completely, then launched it from the terminal with explicit proxy environment variables:

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"

After that, I went back to Settings → Connection → Control This Mac, clicked Allow, and it worked. The phone connected instantly. The whole ordeal boiled down to three commands and a bit of detective work.

Building a Launchpad for Good

Manual exports don't survive a reboot, so I created a dedicated launcher. Using AppleScript, I made a small app that waits 8 seconds for the proxy to start, then launches Codex with the right environment. 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 I added it to Login Items in System Settings and replaced any existing Codex autostart entry. Now, every time I log in, the launcher fires up, waits for the proxy, and starts Codex with the correct settings. It's clean, reversible, and doesn't touch system-wide network configs.

Lessons from the Debugging Journey

What struck me most wasn't the fix itself, but the process. ChatGPT didn't stop at generic advice. It kept pushing, using each piece of new evidence to refine its guesses. It was like having a patient first mate who reads the charts while I handle the sails.

This experience changed how I approach tech problems: when an AI tool misbehaves, ask it to diagnose itself. It understands its own ecosystem better than any third-party guide. I've since adopted this habit for other tools too.

Ultimately, the real takeaway isn't about proxy settings or AppleScript. It's about the collaboration between human and AI—me providing the on-the-ground reality, AI providing the analytical muscle. Together, we can navigate storms that seemed impossible alone.