Crafting a Proxy Launcher: A Maker's Guide to Debugging Remote Art Tools

When the Glue Between Art and Code Stops Sticking

Every maker knows the feeling: you've set up your workspace, your tools are humming, and then something breaks that shouldn't. The connection between your phone and your desktop app—the thing that lets you check on a rendering job or tweak a setting while you're away—refuses to cooperate. It's not the paint, not the brush, but the invisible thread between them.

This happened to me with a remote control feature for an AI art assistant. I wanted to start a complex process on my Mac, then step away and monitor it from my phone. Every attempt ended with the same red error: "Unable to enable remote control." I tried the usual fixes—restarting, logging out, checking permissions—but nothing worked. That's when I decided to treat the problem like a craft project: break it down, examine each piece, and rebuild it with a custom tool.

Treating the Tool as a Workbench

Instead of accepting the error, I began a systematic teardown. I took screenshots of the exact screens, checked the official documentation, and looked at the application's logs. The logs showed the remote control module was starting without errors, but the connection count stayed at zero. It was like a loom that threads the shuttle but never weaves a row.

I confirmed my phone and Mac were on the same workspace—not the project folder, but the broader ChatGPT workspace. That wasn't the issue. I updated the desktop app from version 26.803.61601 to 26.810.50856. Still the same red text. Version wasn't the culprit.

The Hidden Culprit: Proxy Settings

My Mac uses a local proxy to reach the internet, and the main app worked fine. But the remote control's background connection didn't inherit those settings. I tested it with two simple curl commands. Without the proxy, the connection timed out. With the proxy explicitly set, it established immediately.

That was the smoking gun. The remote control feature was trying to go out through a closed door, while the rest of the app used a side entrance. The fix was to give the app explicit instructions to use the proxy when launching.

Building a Custom Launcher: The Maker's Solution

Rather than typing export commands every time, I crafted a small AppleScript application that acts as a dedicated launcher. It waits for the proxy to be ready, then opens the main app with the necessary environment variables. Here's how you can make your own:

1. Quit the main app completely.
2. Open Terminal and run:

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 this app to your login items and keep it in your Dock for quick access. It waits 8 seconds to let the proxy finish booting, then launches the main app with the proxy set.

Troubleshooting Like a Craftsperson

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

• Check your system proxy with scutil --proxy.
• Run curl with and without the proxy to see if it's a proxy inheritance problem.
• Look at the app's logs for clues about where it's failing.

This approach turned a frustrating technical hiccup into a learning experience. It reminded me that even the most digital of tools can be fixed with a maker's mindset: observe, hypothesize, test, and build a custom solution.

Why This Matters for Creative Work

For anyone working in creative fields, the ability to fix your own tools is invaluable. It saves time, reduces dependency on external support, and gives you a deeper understanding of your workflow. This launcher didn't just fix a bug; it gave me control over my environment.

Now I can start a long-running creative process on my Mac, step away, and check on it from my phone. The craft of debugging is just another form of making—turning a broken connection into a seamless part of my creative process.

From Debugging to a Habit of Self-Reliance

This experience taught me a new habit: when a tool fails, ask the tool itself for help. AI assistants can analyze logs, suggest tests, and guide you through fixes. It's not about one correct answer, but about a continuous dialogue that narrows down the root cause.

So next time your creative software throws an error, don't just search for a solution. Roll up your sleeves, inspect the logs, run a few tests, and build a custom fix. You might surprise yourself with what you can craft.