When AI Tools Fail, Let AI Diagnose Its Own Toolchain

The Setup: A Remote Control That Wouldn't Connect

I've been trying to link my phone's ChatGPT app to the Codex desktop client on my Mac. The idea is simple: Codex keeps working on my development tasks while I step away, and I can check progress, send new instructions, or push things forward from my phone. But every attempt to enable remote control failed. I'd hit that red line: "Unable to enable remote control. Please try again."

I tried the usual steps—logging out and back in, restarting, updating the app, checking my account and workspace. Nothing worked. I even asked Doubao, another AI assistant, for help, but it didn't crack it either. I started to suspect account permissions or a network restriction I couldn't see.

The Idea: Let AI Fix Its Own Problem

Then it hit me: if ChatGPT and Codex are part of the same ecosystem, why not let ChatGPT diagnose the issue? So I sent screenshots of my desktop and mobile interfaces to ChatGPT, along with a simple request: "Connect my desktop to my phone."

What followed was a surprisingly effective debugging session. I clicked buttons, took screenshots, and ran commands. ChatGPT analyzed the screenshots, consulted official documentation, suggested commands, read logs, and formed hypotheses. It wasn't a one-shot answer; it was a continuous loop. Each time I fed back the results, it refined its approach. When one hypothesis failed, it discarded it and moved on.

Narrowing Down: It's Not What You'd Expect

We quickly ruled out the obvious suspects. My phone and Mac were on the same ChatGPT account and the same personal workspace. That wasn't the issue. Updating Codex from version 26.803.61601 to 26.810.50856 didn't help either. The red error persisted.

Then we dug into the official logs. On macOS, Codex stores logs at ~/Library/Logs/com.openai.codex/YYYY/MM/DD. Searching for remote control entries, we found lines like:

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

Notice something odd: errorCode is null, and the remote control module seems to start fine, but nextConnectionCount stays at 0. That suggests the problem isn't the toggle itself but something deeper in the connection path.

The Proxy Problem: A Hidden Gotcha

My Mac requires a local proxy to reach ChatGPT. The system proxy settings showed HTTP and HTTPS on 127.0.0.1:33210 and SOCKS on 127.0.0.1:33211. But here's the thing: ChatGPT and Codex's main functions worked fine, so it was easy to assume the network was okay. Yet, an app can have multiple network paths. The main program might use the system proxy, but a background process—like the remote control service—might not inherit those settings.

To test this, we ran two curl experiments. Direct connection to chatgpt.com timed out:

curl -I --connect-timeout 10 https://chatgpt.com
# Failed to connect to chatgpt.com port 443: Timeout was reached

But when we explicitly specified the proxy:

curl -I --proxy http://127.0.0.1:33210 --connect-timeout 10 https://chatgpt.com
# HTTP/1.1 200 Connection established

The HTTPS tunnel established immediately. That was the smoking gun. The remote control's background connection wasn't using the system proxy, even though the main app was.

The Fix: Inject Proxy Variables, Then Automate It

The immediate solution was to launch Codex with explicit proxy environment variables. After quitting Codex, I 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"

That did the trick. My phone connected to the Mac's Codex instantly. But I didn't want to type those commands every time I restarted my computer. So I built a dedicated launcher using macOS's built-in AppleScript compiler. It waits 8 seconds for the proxy software to start, then opens Codex with the environment variables set.

Here's the command I used:

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 the launcher to my login items in System Settings and kept it in the Dock for quick access. I also made sure the original Codex auto-start was disabled to avoid conflicts.

Why This Matters for AI Adoption

This experience taught me two things. First, AI can be a patient debugging partner. It didn't stop after a couple of generic suggestions. It kept asking for screenshots, interpreting logs, and revising its hypothesis. That's a different interaction model than asking a question and getting an answer. It's more like working with a colleague who's determined to find the root cause.

Second, AI seems better at troubleshooting its own ecosystem. ChatGPT knew where to look—the official docs, the log file structure, the specific fields like remoteControl/enable and ConnectionCount. It could connect the dots between the logs and the proxy test results. That's not just about intelligence; it's about having context.

For businesses evaluating AI tools, this is a critical insight. The value of AI isn't just in answering questions or generating code. It's in the ability to diagnose and fix issues within complex toolchains. When an AI product fails, having an AI that can self-diagnose reduces downtime and empowers a single person to solve problems that previously required a dedicated ops team.

The Bigger Picture: Human-AI Collaboration in Practice

This whole episode is a microcosm of what AI-assisted work looks like. I didn't have a manual or a support engineer on call. I had a clear problem, the ability to provide real-time feedback, and an AI that could reason over its own logs and documentation. Together, we narrowed down the issue and fixed it in under an hour.

The takeaway for industry analysts and tech leaders is that AI is evolving from a passive tool to an active participant in system maintenance. As AI becomes more embedded in our development environments, the ability to self-diagnose will be a key differentiator. Products that can inspect their own state, interpret their own logs, and suggest fixes will reduce the burden on human operators.

For the rest of us, the lesson is simple: when your AI tool acts up, let it debug itself. You might be surprised at how effective it can be.