When AI Tools Fail: A Debugging Story from the Trenches

The Dream: Control Your AI From Anywhere

I had a vision. My Mac would run Codex, my AI coding assistant, while I walked away with my phone. I'd check progress, send new instructions, and keep the development pipeline moving without being glued to my desk. This wasn't a pipe dream; the feature was right there in the settings. But every time I tried to enable it, I hit a wall.

The exact error message was maddening: "Unable to enable remote control. Please try again." This wasn't a vague failure; it was a dead end. I'd restart, re-login, re-pair, and still the same red text. I even upgraded Codex from version 26.803.61601 to 26.810.50856, hoping it was just a bug. No luck.

Frustration Leads to a Wild Idea

After several failed attempts, I had a sudden flash of inspiration. I was trying to connect ChatGPT's mobile app to Codex on my Mac. Both are OpenAI products. So why not ask ChatGPT to fix its own problem? I mean, that's what I would do with a colleague. I took screenshots of the desktop and mobile interfaces, sent them to ChatGPT, and typed: "Connect my desktop to my mobile."

That simple request kicked off an unexpected journey. I became the hands-on operator, clicking buttons, taking screenshots, and running commands. ChatGPT became the analyst, examining screenshots, reading logs, and suggesting next steps. It wasn't a one-and-done answer. We went back and forth, chasing leads, hitting dead ends, and revising our approach based on new evidence.

The Usual Suspects: Account, Workspace, Version

We first eliminated the most obvious culprits. My phone and Mac were on the same ChatGPT account, both in the personal workspace. That wasn't the issue. The version was up to date. So what was left? The logs.

I dug into the macOS app logs at ~/Library/Logs/com.openai.codex/YYYY/MM/DD. Searching for 'remoteControl' revealed something intriguing: the enable command had no error code, but the connection count remained at zero. The remote control module was starting, but it wasn't establishing a connection. That pointed away from the feature itself and toward the underlying network path.

The Proxy Problem

My Mac relies on a local proxy to reach ChatGPT. The system proxy was set to HTTP and HTTPS on 127.0.0.1:33210, and SOCKS on 127.0.0.1:33211. Everything looked fine. The ChatGPT app worked, Codex worked, 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 service—like remote control—might not inherit those settings.

To test this, I ran two simple curl commands. A direct connection to chatgpt.com timed out, but specifying the proxy instantly established a connection. That was the smoking gun. The remote control's backend connection wasn't using the proxy.

The Fix: Inject Proxy Variables into Codex

The solution was to explicitly inject the proxy environment variables when launching Codex. I quit Codex completely, then in the terminal ran:

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 went back to Settings > Connections > Control This Mac and clicked Allow, it worked. My phone connected to the Mac's Codex. The mystery was solved: the system proxy was fine, but the remote control service wasn't inheriting it.

Building a Persistent Launcher

Manual exports are a pain. Every time I restart my Mac, I'd have to redo it. So I created a dedicated launcher app that injects the proxy variables only for Codex, without affecting anything else. Using macOS's built-in osacompile, I compiled a small AppleScript app that waits 8 seconds for the proxy software to start, then opens Codex with the necessary environment variables.

The command is simple:

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 my login items and kept it in the Dock for manual launches. If my proxy port ever changes, I just regenerate the launcher. This is clean and reversible—no system-wide changes.

Human-AI Collaboration: The Real Lesson

This debugging session taught me more than just how to fix a proxy issue. It showed me a new way of working with AI. Instead of asking a question and expecting a definitive answer, I engaged in a continuous loop: I provide real-time feedback, the AI analyzes and hypothesizes, I test and report back, and the AI refines its approach. This iterative process led us to the root cause when static troubleshooting had failed.

What struck me most was that ChatGPT seemed better at diagnosing problems within its own ecosystem. It knew the difference between a workspace and a project, it knew where to look for logs, and it understood the significance of the connection count. But it also made mistakes. The key was that it didn't stop at a plausible answer; it kept revising based on new evidence.

So the next time an AI tool acts up, consider asking it to fix itself. You might be surprised at what you can accomplish together.

Conclusion

This experience has changed how I think about AI collaboration. It's not just about using AI to do tasks; it's about partnering with AI to solve problems, even those involving AI itself. The remote control feature now works, but the real win is understanding that with the right approach, a single person can leverage AI to overcome obstacles that once seemed insurmountable. That's the promise of the AI super-individual.