Five AI coding tools, five completely different ways to break

I've now routed five different AI coding tools through a proxy layer. Each one broke differently. None of them told me why.

Writing this partly as a reference for myself, partly because the failure modes turn out to be genuinely interesting — they say a lot about how these tools are built.

Claude Code: reads config once, then never again

The simplest of the five. Config lives in ~/.claude/settings.json, two keys get modified:

env.ANTHROPIC_BASE_URL
env.ANTHROPIC_AUTH_TOKEN

The failure mode: it reads that file exactly once, at startup. Change it while a session is running and nothing happens. No warning, no reload.

This is the single most common "the switch is on but nothing works" report, across every tool. Close all windows, open a fresh one.

One thing I appreciate: it only touches those two keys, backs up the original, and restores it exactly when you flip the switch off.

Codex: doesn't read the model from your request

This one is architecturally weird and cost me an hour.

Every other tool specifies which model it wants in the request. Codex doesn't. It picks from its own internal model catalog.

Consequence: if you don't explicitly select a model, it sits on a default internal GPT model that the market can't serve. And you don't get "please select a model" — you get a string of failures with no stated cause.

The config it writes:

~/.codex/config.toml   → model_provider, [model_providers.asale], model, model_catalog_json
~/.codex/auth.json     → OPENAI_API_KEY

Note model_catalog_json. That's the part that makes your selection show up in the app's model menu. And the desktop app reads that catalog at startup, so a model written while it's running won't appear until you restart. Two separate restart requirements stacked on each other.

Credit where due: it preserves your existing comments and formatting in config.toml. Not every tool does.

Gemini CLI: loses to your own shell config

Config goes into ~/.gemini/.env. Two keys added, nothing else touched.

The failure mode is the nastiest of the five, because everything looks correct:

A real environment variable beats a .env file. Always. If you ever put GEMINI_API_KEY in .zshrc, .bashrc, your system env, or a CI config — that value wins, and the .env is ignored entirely.

Switch is on. Config file is correct. Records page is empty. Nothing anywhere says why.

echo $GEMINI_API_KEY
echo $GOOGLE_GEMINI_BASE_URL

Any output and you've found it. The client does warn about detected conflicts, but I'd suggest just running that echo before flipping the switch. Saves debugging a problem that isn't in the layer you're debugging.

Hermes: two programs, two opinions about where config lives

Of the five, only Hermes doesn't use ~/.<toolname>. Its resolution order:

1. HERMES_HOME if set
2. An existing config.yaml — either ~/.hermes or %LOCALAPPDATA%\hermes, whichever exists
3. Falls back to ~/.hermes

The trap is in step 1. The installer writes HERMES_HOME as a user-level environment variable — and a terminal opened before you installed Hermes doesn't have it. Environment variables are read at process start.

So: the proxy client, running in an environment without HERMES_HOME, follows rule 3 and writes to ~/.hermes. Hermes itself follows HERMES_HOME and reads from %LOCALAPPDATA%\hermes. Two paths, no error, no traffic.

On Windows the default isn't ~/.hermes at all — it's C:\Users\you\AppData\Local\hermes.

Fix: restart your terminal after install, and fully quit and relaunch the proxy client so it picks up the new user-level variable. The buy page displays the path it resolved — compare it against what Hermes actually uses before assuming anything else is wrong.

OpenClaw: identified by a URL path segment

Config is ~/.openclaw/openclaw.json. Open it and you'll notice the endpoint URL has a trailing /openclaw. It looks like someone pasted wrong.

It isn't. Here's why:

Every other tool's requests have a recognizable shape. OpenClaw's don't — its requests can be byte-identical to Claude Code's or Codex's. There is no way to tell them apart from content alone.

So the path prefix is the identifier.

Delete it and OpenClaw's traffic gets classified as Codex — using Codex's switch, Codex's selected models. The failure is quiet: requests still go through, still get billed, just against a configuration you didn't choose.

You'd never hit this unless you hand-edit the config. If you do, leave the prefix. If you already removed it: re-apply from the buy page, restart.

The pattern across all five

Every one of these fails silently. Not one returns "you didn't select a model" or "your config is being overridden" or "I'm reading a different file than the one you wrote."

Which is why my debug order is now fixed:

1. Did I restart the tool? (fixes most of them)
2. Is the config file where the tool actually looks? (Hermes)
3. Is something overriding it? (Gemini env vars, or a tool that rewrote its config on upgrade)
4. Is a model actually selected? (Codex)
5. Is the URL intact? (OpenClaw)

Five checks, under two minutes, covers essentially everything.

Context, since this all needs one

I'm running these through Asale — a market where people's unused subscription capacity gets routed to people who need it. I use it because my usage is uneven enough that a monthly tier is either wasted or insufficient, never right.

The tradeoff worth knowing before you try it: requests relay through another user's client, so the payload is visible at that hop. Not end-to-end encrypted, and they say so themselves on the front page. Personal and open source work, yes. NDA'd code, no.

Client's open source. Given that it rewrites config files and relays requests, I'd read what it sends before running it.

---

Have you hit a failure mode I didn't list? Genuinely interested — I suspect there are more of these.