Developer moved Claude Code authentication to a VDS while keeping projects on a Mac

In October, many Claude users in Russia and neighboring countries once again saw their accounts suspended. The author of the Habr write-up lost his Max subscription one day before the payment was due, and support, as he reasonably assumed, would not have resolved anything. He bought a new subscription and assembled a configuration in which the projects remain on his Mac, while Anthropic authentication and network egress reside on a Linux server. This is a personal experiment, and the author himself stresses that it should not be treated as a universal guide.

Why Remote SSH and a simple proxy were not enough

The first idea was the most obvious one: install Claude Code on the VDS and connect through VS Code Remote SSH. That works, but projects from the Mac do not automatically appear on the server. Repositories can be cloned and synchronization configured, but the author did not want to keep some files on someone else's machine. The resulting requirement was this: Claude Code must read and modify files on the Mac, model requests must go out through Linux, and authentication must remain on Linux.

The second idea, an HTTP proxy on the server, did not work either. A proxy changes the traffic route, but it does not provide the client on the Mac with authentication from another machine. Two separate components were therefore required. CLIProxyAPI is a gateway that accepts requests from the local Claude Code client and contacts Anthropic using the server-side credentials. Tinyproxy forwards the client's remaining traffic: web searches, MCP, and other requests that would otherwise originate from the home IP address.

How the setup works

On the Mac, settings.json defines ANTHROPIC_BASE_URL as a local port, HTTP_PROXY and HTTPS_PROXY as a second port, while apiKeyHelper supplies the gateway key. Both ports are forwarded through a single SSH tunnel to the server, where the gateway and proxy listen only on 127.0.0.1. A LaunchAgent starts and restarts the tunnel. The model itself, of course, computes its response in Anthropic's cloud. The gateway, token, and network egress remain on the server; the files, agent, and execution of local tools remain on the Mac. Only file fragments selected by the agent and the results of local commands are sent to the model.

The author performed numerous checks because pitfalls appeared at every step. He verified the external IP through the proxy, inspected the VS Code extension binary, and confirmed that file operations ran on the Mac. He also launched the client separately while the gateway and proxy were unavailable: no response arrived through an alternative route, only a connection error.

Where everything broke

The first problem was systemd. The authentication import in ExecStartPre could not see the required environment variable, so the service failed before the gateway started. The author ran the import separately, after which the service read a prepared auth file. The token must be updated manually.

The second problem was NO_PROXY. Without a loopback exception, requests to the local gateway first went to Tinyproxy, and nothing worked.

The third and most instructive issue was the model catalog. The client requested the auxiliary model claude-haiku-5-5, which was absent from the CLIProxyAPI 8.0.20 catalog, and received an unknown provider for model error. The fix was to add a record for the model to the catalog. The author concludes that the client and gateway versions should be pinned and upgraded deliberately.

There is another limitation: after sleep or a network interruption, the tunnel reconnects, but a model request that has already been interrupted does not resume.

What to take away and what to keep in mind

The pattern is useful beyond the context of account blocks. If credentials and network egress need to remain on one machine while files and tools stay on another, the combination of a local agent, a gateway behind an SSH tunnel, and a separate proxy works. It also demonstrates that an API gateway and a network proxy solve different problems and do not replace each other.

However, the approach comes with serious caveats. The author acknowledges that having a VDS does not override Anthropic's requirements concerning the user's actual location, and that matching the countries of the payment card, SIM, and server guarantees nothing. He also shares the subscription with a friend, creating another risk area: shared services and ports on one VDS, with several users holding root access.

The setup-token is stored on the server, making the server a critical point. Circumventing regional restrictions and sharing a subscription may violate the service terms, so the account could be lost again. Teams are better off using this architecture where they have legitimate access and need centralized egress, not as a way to evade the provider's rules.

The Habr article ends midway through an examination of collaboration details, so it does not provide a complete picture of shared access.