Build1 distinct publisher3 min readUpdated
A dev.to writeup shows ANTHROPIC_BASE_URL set in a terminal does not reach the VS Code extension's agent process, which inherits the editor's environment instead.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Exporting `ANTHROPIC_BASE_URL=http://127.0.0.1:20128` in a shell does route the `claude` CLI to a local endpoint [1]. Open the Claude Code panel in VS Code in the same project and it still talks to Anthropic directly [2]. If your compliance story is "we set the base URL and all agent traffic goes through our gateway," half your traffic is probably not going through your gateway.
The mechanism, per a dev.to writeup by Vinh Nguyen Thanh, is unremarkable once stated: the CLI reads the environment of the process you launched it from [3], while the extension spawns its agent process from the VS Code window process, so it sees whatever environment VS Code itself was started with, typically the desktop or login environment [4]. That produces two failures pointing in opposite directions. Export in a terminal and then open the panel, and nothing happens, because the panel never saw the variable [5]. Launch VS Code from that terminal so it inherits the variables, and now every workspace in that window is routed, including the ones you wanted talking to Anthropic directly [6].
The only hook the extension offers is a settings key, `claudeCode.environmentVariables`, a list of name and value pairs injected into the agent process [7]. The author's audit is a `jq` read of the user settings file, at `Library/Application Support/Code/User/settings.json` on macOS, `.config/Code/User/settings.json` on Linux, and `$APPDATA/Code/User/settings.json` on Windows [8]. On a machine that has never been switched it prints nothing set, meaning the extension is inheriting the VS Code process environment [9]. That is the check worth running across a fleet, because a shell profile audit will tell you nothing useful about the panel [22].
The key has machine scope, not workspace scope: turn routing on for one project and every VS Code window on that box is routed [10]. So per-repo enforcement is not available through this hook at all [23]. Turning it off means deleting entries rather than flipping a flag, and if you remove the token but leave `ANTHROPIC_BASE_URL` behind, the panel points at a router with no credential [11]. The array is also shared with unrelated variables such as proxy settings or `NODE_EXTRA_CA_CERTS`, one careless overwrite from disappearing [12].
The author's response is a toolkit that treats the array as partly owned, managing exactly six names and writing back everything else untouched [13][14], with a `settings.json.bak-claude-router` copy taken before any write and a restore-and-exit-non-zero path if serialisation throws [15]. Switching on or off requires a Developer: Reload Window, because the agent process reads its environment once at spawn [17]. On the CLI side the wrapper stays in process scope, unsetting `ANTHROPIC_API_KEY` so a leftover key cannot beat the router token, then exec'ing `claude` [18]. The stated cost of the asymmetry: you cannot have one routed window and one direct window at the same time [20]. The endpoint in question is a 9Router instance exposing an Anthropic-compatible `/v1/messages` in front of multiple providers, configured from a gitignored local file [21].
Two things to watch. First, whether the extension ever gains a workspace-scoped environment hook, which is the difference between per-repo policy and per-laptop policy [23]. Second, your gateway's request counts against seat counts, since a panel that silently bypasses the proxy shows up as absence, not as an error [9][5].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Running `export ANTHROPIC_BASE_URL=http://127.0.0.1:20128` in a shell routes the claude CLI to a local endpoint.
Opening the Claude Code panel in VS Code in the same project, after that export, still talks to Anthropic directly.
The claude CLI reads the environment of the process it was started from.
The VS Code extension spawns its agent process from the VS Code window process, so its environment is whatever VS Code itself was started with, that is the desktop or login environment rather than the shell where the export was typed.
Consequence one: export in a terminal, then open the panel, and nothing happens because the panel never saw the variable.
Consequence two: launching VS Code from that terminal so it inherits the variables routes every workspace in that window, including ones where the default Anthropic connection was wanted.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-authored post, but with a reproducible check
One source carries the whole cluster. Its central mechanism claim is internally coherent and independently checkable by any reader via the supplied jq snippet against the documented settings paths, which lifts it above pure assertion. Nothing else corroborates it: no Anthropic or extension documentation, no second practitioner report, and the toolkit's safety behaviour (pre-write backup, restore and non-zero exit on serialisation failure) is asserted without shown tests. The author also states plainly that no latency or cost figures were measured.
No usage data beyond the author's own repository
The only adoption-shaped fact supplied is that the author published an MIT-licensed, Windows-only toolkit with three open porting issues. There are no stars, downloads, installs, deployments, third-party users or organisational rollouts in the material, and the extension-side behaviour is reported by one developer on one platform. Nothing in the sources supports estimating uptake, so this dimension is left unmeasured rather than inferred.
Claims stay inside the author's own stated limits
The post consistently under-promises relative to what it demonstrates. It offers a diagnosis and a check rather than a product pitch, explicitly refuses benchmark or cost claims, states that routing the client does not make the model Claude, flags that tool use, streaming, vision and prompt caching vary by provider, warns that some subscriptions and OAuth sessions are not licensed for router use, and names Windows-only support with porting unfinished. The mildly negative reading reflects that the most broadly useful finding, that per-workspace gateway enforcement is impossible through the extension's only hook, is presented as a personal workflow note rather than the governance issue it is.
Author promotes his own repository and solicits contributions
The writeup is authored by the maintainer of the toolkit it recommends and ends by linking the repository, naming three open issues, and asking readers to run the diagnostic and report results, which is recruitment for a project the author owns. The routed endpoint is also a specific named product, 9Router. Offsetting factors keep this mid-range rather than high: the code is MIT-licensed with no pricing, subscription or referral mechanism disclosed in the source, no provider is hard-coded, and the limits section works against the author's promotional interest.
Mechanism credible and checkable; toolkit specifics unverified
Confidence is moderate. The environment-inheritance explanation, the two failure directions, and the settings-key audit path hang together and can be confirmed by a reader in one command, and the machine-scope consequence follows directly from the extension's documented hook. What lowers it: a single self-interested publisher, no corroborating documentation, platform coverage limited to Windows in practice, unverified internal guarantees about the toolkit's write path, and no adoption evidence at all.
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
build
Your Multi-Key Failover Is The Most Expensive Line On Your Coding Agent Bill1 distinct publisher
build
A session that read "finished" and "still executing" was a slow queue, not a dropped handshake1 distinct publisher
build
The $559M-versus-$12.3B quarter matters more than the $65B run rate4 distinct publishers
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026