What Free Claude Code Actually Proves About Coding Agents
There’s a story going around that a free, open-source project called Free Claude Code works by tricking Claude Code’s extension into accepting a fake identity. That story is only half right, and the half it gets wrong matters.
Free Claude Code works because Claude Code was built to read two environment variables — ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN — and to send its requests wherever they point. That’s a documented feature, designed for corporate gateways. Free Claude Code, an MIT-licensed Python project that runs a local proxy on your own machine, uses exactly that door.
So no, there’s no authentication exploit here. But there is an identity question worth taking seriously — just not the one most people are asking. The real question isn’t whether the login can be swapped. It’s whether the thing answering on the other end is still Claude at all, and what it means when a tool wearing Claude’s name hands you output from a model that has never seen Anthropic’s training data.
Why the Debate Started at All
Coding agents got popular fast. Everyone has one open in a terminal or an editor, everyone burns through tokens, and everyone eventually looks at the bill. Then a project appears that says: run Claude Code, Codex, Pi, OpenCode, and more, for free, from your terminal, app, IDE, or phone. Of course people notice.
And then the second reaction comes: if it works without paying for the vendor’s own API, something must be broken. Right?
Not quite. A coding agent is just a client. It speaks a wire format, sends an Authorization header, and reads a base URL from configuration. Anthropic’s own documentation describes an LLM gateway as a proxy an organization runs between the agent and the model provider, and it tells you exactly which variables to set for it. Enterprises asked for that, and it shipped. Free Claude Code is one developer flipping the same switch a bank’s platform team would use — just pointed at localhost instead of a corporate firewall.
So the interesting part was never the trick. There is no trick, at the level of authentication. The interesting part is what a configurable endpoint means for the person who configures it — and for everyone who later assumes they’re talking to Claude when they’re not.

How It Works
The project lives at Alishahryar1/free-claude-code on GitHub. Python, MIT license, and its README says the important thing plainly at the top: independent open-source project, not affiliated with or endorsed by Anthropic; Claude and Claude Code are trademarks of Anthropic. That disclaimer is doing more honest work than most of the commentary around the project.
The mechanism, as described in the project itself: install with a shell or PowerShell one-liner, start the local server, open the Admin UI, paste in a provider key, pick a model from a searchable dropdown, click Apply. Then run your agent through a wrapper command, and it talks to the proxy instead of Anthropic’s API.
The Settings That Redirect the Agent
For the VS Code integration, you add environment variables to your user settings JSON:
Setting | Typical value | What it does |
|---|---|---|
|
| Sends agent requests to the local proxy instead of the vendor endpoint |
| any string | Value used for the Authorization header, matched to the Admin UI |
|
| Stops the extension asking you to sign in |
|
| Lets the client discover models offered by the gateway |
Notice what the token is: an arbitrary string, not a signed credential and not something with a checked prefix. And that’s not a bug someone found — Anthropic’s own environment-variable reference describes ANTHROPIC_AUTH_TOKEN as a custom value for the Authorization header, prefixed with Bearer, precisely because corporate gateways use their own token formats. Any string works. By design.
Two Different Identity Questions — and Why the Popular Framing Only Answers One
This is where most write-ups about Free Claude Code stop, and it’s also where they go slightly wrong by treating the identity question as settled. There are actually two separate identity questions bundled together here, and only one of them gets resolved by pointing at the documentation.
The authentication identity question is genuinely settled. No exploit hides behind the freecc token or any string like it. ANTHROPIC_AUTH_TOKEN was never a credential the client verifies — it’s a pass-through value for a header, and Anthropic’s documentation says so outright. Calling this “faking your identity” is a category error, on the level of calling a blank form field a security hole because it accepts anything you type into it.
The model identity question is not settled, and deserves to be named directly. When someone configures MODEL_OPUS to point at a model from NVIDIA, Qwen, or any other provider, Claude Code’s interface still labels it as the “Opus” tier. The picker still says Claude. The terminal still runs under the name Claude Code. But the thing actually generating the response is not Claude — it’s a different model entirely, routed in through variables that were built so a company’s real Anthropic gateway could sit transparently in the middle, not so an unrelated model could borrow Anthropic’s tier names and product identity.
That’s a real assumption of a false identity — just not the technical, authentication-layer kind that gets debunked in the first paragraph of every take on this project. It’s a branding-layer identity question: a user, or more importantly a teammate reading that user’s output later, has no reliable signal that “Claude” in their editor is actually Claude. The project’s own trademark disclaimer — “not affiliated with or endorsed by Anthropic” — is honest about the company relationship. It says nothing about the fact that, once configured, the tool can silently present a completely different model’s output under Claude’s tier names inside a UI still called Claude Code.
This distinction matters because the two questions call for different responses. You don’t fix the authentication question — there’s nothing broken there. But the model-identity question is a genuine gap: nothing in the interface tells a user, mid-session, “this response did not come from Claude.” That gap is exactly what should worry a team more than the login mechanics ever should.

Where the Trust Actually Sits
So if there’s no login exploit, is there no risk? There’s plenty — it just lives in different places than the headlines suggest.
Think about what a coding agent sends: your file contents, your error strings, your prompts, which often describe exactly where your system is weak. Point the base URL at a proxy, and the proxy sees all of it — in cleartext if the URL is http://, which is fine on localhost and not fine at all on someone else’s host. That lesson applies to every OpenAI-compatible gateway, not to one repository.
The project does take the local surface seriously. It supports protecting the proxy with a bearer token, and its Codex integration doesn’t even ask you to paste a secret — it runs a command that reads the current token automatically. That’s a better pattern than a hardcoded string in a settings file.
The gap isn’t in the token. The gap is that a base URL is a trust decision, and nothing in a text field tells you how much trust you just spent — or which model is actually on the other end of it.
Terms of Service, Not Certificates — and Not Just Branding Either
People reach for the word “vulnerability” because it sounds decisive. It’s mostly the wrong word here. The real vocabulary is different:
Configurable endpoint — a documented client setting that sends agent traffic to a chosen host. Intended for gateways, not an exploit.
Local proxy — a service on your own machine that receives agent requests and forwards them to a provider.
Provider terms — the contract that governs whether a given key may be used from a coding agent at all. Several plans are flagged as personal, interactive use only, with keys and endpoints that are not interchangeable with team or commercial use.
Model identity — what a UI element labeled “Claude” or “Opus” actually is, once the base URL no longer points at Anthropic. This is the one category most commentary skips.
A developer wiring a personal-use key into a team workflow isn’t a TLS problem — it’s a compliance problem. And a developer whose teammates believe they’re reviewing Claude’s reasoning, when the actual output came from an unrelated model routed in under a Claude tier name, isn’t a login problem either. It’s an identity problem the tooling doesn’t surface.
To its credit, the client side isn’t fully defenseless: Anthropic’s documentation confirms that when the base URL points at a non-first-party host, MCP tool search is disabled by default, and as of a recent version, Remote Control is disabled entirely when the base URL isn’t api.anthropic.com. Features degrade on purpose once you leave the vendor’s endpoint — a signal, even if a quiet one, that something has changed.
What a Security Team Should Actually Do About It
Don’t panic, and don’t ban a repository. Treat the endpoint — and the model behind it — as the control point, because it is.
Manage the variables. If the base URL and the auth token can be set from a project file or an editor setting, they’re configuration you should be shipping and auditing, not discovering after the fact.
Log the hosts. You don’t need to read prompts to know that agent traffic left for an address nobody approved.
Write the key policy down. Which provider plans may be used from a corporate machine, and which are personal-only. Enforce it on keys, not on tools.
Make model identity visible. If a tier has been rerouted away from an Anthropic model, that fact should be loud somewhere — in a status line, a log, a banner — not buried in a settings file only the person who configured it will ever open.
Separate the machines. A router that can reach dozens of providers has no business sitting on a laptop with production credentials.

The Part Everyone Skips
Free Claude Code is a well-built local router with a long provider list, a real admin interface, an MIT license, and a proxy token you can lock down. It’s also proof that the thing standing between your codebase and a stranger’s server — and between your team and knowing what actually generated a piece of code — is a text field in a settings file.
So use it as an argument, by all means, but make the right one — and make both halves of it. Don’t say “the extension accepts a fake identity” about the login, because that’s not true and anyone who reads the gateway documentation will correct you. But don’t stop there either, and don’t let the correction talk you out of the part that is true: once the base URL moves, the model can be anyone, the interface will keep calling it Claude, and nothing in the product tells the next person in the chain that the name on the label and the model that did the work are no longer the same thing.
This article includes content created with AI.

