Fixing Codex Remote Control: A Debugging Journey with ChatGPT

When AI Tools Break Themselves

There's a strange satisfaction in watching an AI tool diagnose its own problems. Not just answer questions about how to use it, but actually dig into logs, run experiments, and figure out why its own connection is failing. That's exactly what happened when I tried to link ChatGPT on my phone to Codex on my Mac.

I've been using Codex as a digital developer for my product. It modifies code, runs tests, analyzes bugs. The problem? I wanted to leave my desk and still monitor what it was doing, send new instructions from my phone, and keep the work moving. The Remote Control feature promised exactly that. But every time I tried to enable it, I hit the same wall.

The Red Text That Wouldn't Go Away

On my Mac, I'd go to Settings > Connection > Control This Mac, click Allow, and immediately see: Unable to enable remote control. Please try again.

I restarted. I logged out and back in. I re-paired the phone. I clicked Allow so many times I lost count. Nothing worked. My first suspects were account permissions or a workspace limitation. But neither panned out. My phone and Mac used the same ChatGPT account and the same personal workspace. That wasn't the issue.

I even checked for updates. My Codex version was 26.803.61601, and an update to 26.810.50856 was available. I installed it. Same red text. So much for that theory.

Turning the Problem Over to ChatGPT

At that point, I had a thought: Why not ask ChatGPT to fix its own connection problem? I took screenshots of both the phone and desktop screens, sent them to ChatGPT, and typed: Connect my desktop to my phone.

What followed wasn't a single answer. It was a back-and-forth debugging session. I clicked buttons, took screenshots, ran commands. ChatGPT analyzed what I sent, suggested next steps, and adjusted its approach based on what I reported back. It wasn't always right—we went down a few dead ends—but it never just gave up and settled for a half-baked answer.

Digging Into Logs

ChatGPT pointed me to the official Codex log location: ~/Library/Logs/com.openai.codex/YYYY/MM/DD. I searched for Remote Control entries and found something telling:

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

No error code. The module seemed to start fine. But the connection count stayed at zero. That suggested the problem wasn't the feature itself—it was something deeper, likely in the network path.

The Proxy Suspect

Here's the tricky part: My Mac uses a local proxy to access ChatGPT. Without it, there's no connection. The system proxy settings showed HTTP and HTTPS at 127.0.0.1:33210, and SOCKS at 127.0.0.1:33211. ChatGPT worked fine. Codex worked fine. So I assumed the network was fine.

But a desktop app can have multiple network paths. The main program might use the system proxy correctly, while a background component—like the Remote Control service—might not inherit those settings. To test this, we ran two quick experiments.

Experiment 1: Direct Connection

I ran a curl command without any proxy:

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

Result: Failed to connect to chatgpt.com port 443: Timeout

Experiment 2: With Proxy

Then I specified the local HTTP proxy:

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

Result: HTTP/1.1 200 Connection established (even though Cloudflare later returned a 403, the tunnel itself worked).

The contrast was clear: direct connection timed out, proxy connection succeeded. Combined with the logs, it pointed to one thing—Codex's Remote Control wasn't inheriting the system proxy.

The Fix: Inject Proxy Variables

To test this, I did something reversible. I quit Codex completely, then launched it from the terminal with 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"

I went back to Settings > Connection > Control This Mac, clicked Allow, and this time it worked. My phone connected to my Mac. The root cause was confirmed: the main app could use the system proxy, but the Remote Control background connection didn't inherit it automatically.

Building a Permanent Launcher

That terminal command worked, but it wasn't practical for daily use. I didn't want to open a terminal every time I needed to start Codex. So I built a small dedicated launcher that does two things: waits for the proxy software to start, then opens Codex with the right environment variables.

Using macOS's built-in osacompile, I created an AppleScript app. The script looks like this:

delay 8
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"

I saved it as Codex-Proxy-Launcher.app in my Applications folder, then added it to my login items. Now, whenever I log in, the launcher waits 8 seconds for my proxy software to boot, then starts Codex with the proxy variables set. If I ever need to restart Codex, I just quit it and click the launcher.

A Few Notes

• If you have the original Codex or ChatGPT app in your login items, disable it. Keep only the launcher.
• Make sure your proxy software itself is set to start at login, so the 8-second delay is enough.
• If your proxy ports change, you'll need to regenerate the launcher with the new values.

This approach is clean and reversible. To undo it, just remove the launcher from login items and delete the app. It doesn't modify any system network settings and doesn't affect other software.

Why This Worked

Looking back, two things made the difference. First, ChatGPT was patient. It didn't stop after a couple of generic suggestions. It kept asking for screenshots, reading logs, proposing tests, and updating its approach based on what I found. It was willing to be wrong and try again.

Second, and maybe more interesting, ChatGPT seemed better at debugging issues within its own ecosystem. It knew where to look in the logs, what fields mattered, and how to connect the dots between the log output and the network tests. It wasn't magic—it was just better at navigating the system it was built for.

This experience changed how I approach AI tool problems now. If an AI tool isn't working, I let the AI itself help diagnose the issue. It's not always right, but with me providing real feedback and executing tests, we can usually narrow things down to the actual root cause.

More Than a Connection

Sure, I can now control Codex from my phone while I'm away from my desk. That's convenient. But the bigger takeaway is the collaboration model: I provide the context and run the experiments; the AI analyzes, hypothesizes, and refines. It's not about getting a single correct answer—it's about working together to corner the problem until it can't hide anymore.

For anyone stuck with the same issue, here's a quick checklist: if your ChatGPT and Codex work fine, your phone and Mac are on the same account and workspace, but Remote Control won't enable, and you use a proxy—check whether the remote connection is actually going through the proxy. Run scutil --proxy to see your system settings, then test direct versus proxied connections. If direct times out and proxied works, you've found your culprit.

This was a small problem, but it was a perfect example of what I call the AI super individual—one person, no team, just knowing how to ask the right questions, feed the AI with real feedback, and take responsibility for the outcome. That's enough to solve problems that would have stumped me for hours before.