When Your Remote Control Won't Connect, Let the AI Debug Itself

I'm a product developer who relies heavily on AI coding tools. My Mac runs Codex, and I wanted to control it from my phone—to check on long-running tasks, append instructions, and keep the work moving even when I'm away from my desk. But every time I tried to enable remote control, I hit a wall. The Mac app would show a red error: "Unable to enable remote control. Please try again."

I tried everything I could think of: logging out and back in, restarting, updating the client, checking account permissions, and confirming both devices were on the same workspace. Nothing worked. I even asked another AI assistant for help, but it just gave me generic advice that didn't solve the problem.

The Idea: Let the AI Fix Its Own Toolchain

One day, I had a thought: since the problem was with ChatGPT/Codex, why not let ChatGPT itself figure it out? I took screenshots of the phone and desktop interfaces and sent them to ChatGPT with a simple request: "Connect my desktop to my phone."

What followed was a collaborative debugging session. I'd click buttons, take screenshots, and run commands; ChatGPT would analyze the screenshots, consult official docs, suggest diagnostic steps, read logs, and adjust its hypotheses based on my feedback. It wasn't a one-shot answer—it was an iterative process.

Narrowing Down the Culprit

We first ruled out the obvious suspects. The phone pairing process is straightforward: Settings → Remote Control → Add Connection → Pair New Device. Both devices were on the same ChatGPT workspace (personal, not business or enterprise), so that wasn't it.

Next, I updated Codex from version 26.803.61601 to 26.810.50856, hoping it was a bug fix. Still the same red error.

Diving into the Logs

We then looked at the official macOS logs for Codex, located at ~/Library/Logs/com.openai.codex/YYYY/MM/DD. Searching for remote control entries revealed something interesting:

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

The remoteControl/enable method didn't return an error, and the connection count stayed at zero. That suggested the issue wasn't with the toggle itself, but with the underlying network path.

The Proxy Problem

My Mac uses a local proxy to access ChatGPT. The system proxy settings showed HTTP and HTTPS on port 33210, and SOCKS on 33211. The main ChatGPT app and Codex could connect fine, so I assumed the network was okay. But we suspected that the remote control's background connection might not inherit the system proxy.

We ran two quick tests:

• Direct curl to chatgpt.com without proxy: timed out.
• Curl with the local proxy: immediately established an HTTPS tunnel.

The conclusion was clear: the remote control feature wasn't using the proxy.

The Fix: Inject Proxy Environment Variables

To verify, I quit Codex completely and relaunched it from the terminal with the proxy 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"

This time, when I clicked "Allow" in the remote control settings, it worked. My phone connected to Codex on the Mac.

This is a temporary fix, though. The environment variables only apply to that terminal session. To make it permanent, I created a dedicated launcher app using AppleScript.

Building a Persistent Launcher

Using osacompile, I built a small app that waits 8 seconds (to let the proxy software start), then launches Codex with the proxy variables. I placed it in my Personal Applications folder and added it to my login items. Now, whenever I restart my Mac, the launcher starts Codex with the correct proxy settings automatically.

Here's the command I used (adjust the ports to match your proxy):

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"'

I also removed the original Codex login item to avoid duplicate launches. The launcher is clean and reversible—deleting it from login items and trash is all it takes.

What This Taught Me About Human-AI Collaboration

This debugging session was more than a fix—it was a new way of working. The AI didn't just give me a one-off answer; it stayed engaged, revised its hypotheses as new evidence came in, and helped me narrow down the root cause step by step. I provided the environment and actions; it provided the analysis and knowledge.

Sure, it made wrong guesses along the way, but that's part of the process. The key is that the human keeps feeding real-world feedback, and the AI keeps refining its approach. That's how we solved a problem that had stumped me for weeks.

Practical Takeaways

If you're facing a similar issue, here's a quick checklist:

• Ensure both devices use the same ChatGPT workspace.
• Check if your network requires a proxy to reach ChatGPT.
• Test with curl: direct vs. proxy.
• If direct fails, launch Codex with proxy environment variables.
• Create a launcher for persistence.

This experience has changed how I approach troubleshooting with AI tools. When something goes wrong, I now think: "Let the AI debug its own ecosystem." It's a powerful partnership—one that turns a frustrating error into a learning opportunity.