When Remote Control Fails, Let AI Diagnose Its Own Toolchain

When Codex Wouldn't Connect

I wanted my phone's ChatGPT to control Codex on my Mac. That way, I could start a long dev task, walk away, and still check progress or push new instructions from anywhere. The feature was right there in the settings, but every attempt ended with the same red text: Unable to enable remote control. Please try again.

I'd been through the usual motions: re-login, restart, re-pair, update the app. I even asked another AI for help. Nothing stuck. The app worked fine, Codex wrote code normally, so I assumed it was an account permission or a network quirk I couldn't fix.

A New Idea: Let the AI Fix Itself

One day it hit me: why not ask ChatGPT to debug its own product? I sent screenshots of both the phone and desktop interfaces, then typed a single instruction: “Connect my desktop and phone.”

What followed was a genuine back-and-forth. I clicked buttons, took screenshots, ran commands. ChatGPT analyzed the screens, consulted official docs, gave me log paths, and adjusted its guesses based on each new result. It wasn't a one-shot answer. It was a conversation that kept narrowing the possibilities.

Ruling Out the Obvious

First, we checked the obvious suspects. The phone app had a Remote Control section under Settings, and the pairing flow requires the same ChatGPT workspace on both devices. My phone and Mac were already on the same account and personal workspace, so that wasn't it.

Next, I updated Codex from version 26.803.61601 to 26.810.50856. Still the same red error. So it wasn't a simple version bug.

Digging into Logs

We turned to the official logs. Codex on macOS stores them at:

~/Library/Logs/com.openai.codex/YYYY/MM/DD

Searching for Remote Control entries, we 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, no creation failure, but connection count stayed zero. That pointed away from the toggle itself and toward the underlying network connection.

Proxy Puzzles

My Mac needs a local proxy to reach ChatGPT. The system proxy was set to HTTP 127.0.0.1:33210, HTTPS 127.0.0.1:33210, and SOCKS 127.0.0.1:33211. Everything worked: ChatGPT loaded, Codex ran. So I assumed networking was fine.

But a desktop app often uses multiple network paths. The main program might respect the system proxy while a background service doesn't. We tested with two curl commands:

• Direct connection to chatgpt.com without proxy: timed out.
• With --proxy http://127.0.0.1:33210: got HTTP/1.1 200 Connection established instantly.

That confirmed it: Codex's remote-control backend wasn't inheriting the system proxy.

The Fix: Inject Proxy Environment Variables

We did a reversible test. I quit Codex completely (⌘Q), 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"

Back in Settings → Connections → Control This Mac, I clicked Allow. It worked. The phone connected to the Mac's Codex.

Those port numbers are specific to my proxy software. Yours will differ, so adjust accordingly.

A Cleaner Launcher for Everyday Use

Typing those exports every time is tedious, and they only last for that terminal session. To make it persistent without messing with system settings, I built a tiny AppleScript app that waits 8 seconds (so the proxy is ready), then launches Codex with the environment set.

Run this in Terminal (after quitting Codex):

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 it to System Settings → General → Login Items, and optionally drag it to your Dock. If you already have Codex or ChatGPT in login items, remove those so only the launcher starts it.

If your proxy ports change, regenerate the launcher with the new numbers. To undo, delete the app from Applications and remove the login item. It's clean and reversible.

How to Spot This Problem Yourself

If you're stuck with the same error, check for these conditions:

• ChatGPT and Codex work fine normally.
• Your phone has the Remote Control entry, and both devices use the same account and workspace.
• Clicking "Allow" on the Mac always fails, even after restarts and re-pairing.
• You need a proxy to reach ChatGPT.

If that sounds familiar, run scutil --proxy to see your system proxy, then test with curl as I did. If direct fails and proxy works, you've found your culprit.

What This Taught Me About Human-AI Collaboration

This wasn't a one-shot answer. It was a continuous loop: I provided real-world evidence, ChatGPT formed hypotheses, I ran experiments, and we refined the approach. The AI didn't stop at a plausible but wrong solution. It kept adjusting until we found the root cause.

There's also something to be said for letting an AI debug its own ecosystem. ChatGPT knows its own product, docs, and logs. It could connect the dots between account settings, workspace types, log entries, and proxy behavior. That's a powerful capability.

Now I have a new habit: if an AI tool breaks, I ask it to diagnose itself. It won't always get it right, but with real feedback, it can get closer.

This experience also reinforced a bigger picture. A single person, armed with the ability to describe problems clearly and feed real data, can operate like a one-person company. No big team, no dedicated ops. Just knowing how to collaborate with an AI to push through a problem.

The fix itself was simple—three export commands and a launcher. But the real value was the evidence chain that led there. That's the kind of debugging I want to keep doing.