Managing Claude AI Agents Offline: A Developer's Guide

What offline actually means for a Claude agent

Claude Code, the terminal agent, and the Claude models behind it are two different things. The agent harness runs on your machine: it reads files, edits code and runs shell commands locally. The model that decides what to do next does not run on your machine. Anthropic has not released the weights behind Claude, so every reasoning step is a network call to a server, either api.anthropic.com directly or a cloud account you have set up through AWS, Google Cloud or Microsoft Azure.

That makes true offline use impossible for the thinking part of the agent. What developers usually mean by offline is something narrower: keep my code and files on my own machine, route the connection through my own network controls, or keep a session alive through a flaky connection instead of watching it fail. All three of those are real and solvable. A fully disconnected Claude agent is not.

Claude Code's own documentation lists the exact hosts a session needs to reach, starting with api.anthropic.com for every API request, claude.ai and platform.claude.com for sign-in, and registry.npmjs.org for plugin or npm-based MCP installs. Block api.anthropic.com on your firewall and the agent cannot think, no matter how good the local sandbox around it is.

• The agent harness, file edits and shell commands, runs locally.
• The model's reasoning always requires a network call, direct to Anthropic or through a cloud provider.
• api.anthropic.com is the one host every Claude Code session needs, whichever install method you use.
• There is no supported way to run the Claude models themselves on your own hardware.

The closest you can get: routing, not disconnecting

If your organization already blocks most outbound traffic, the realistic goal is a controlled path, not no path. Claude Code reads the standard HTTPS_PROXY, HTTP_PROXY and NO_PROXY environment variables, so you can send every request through a corporate proxy that logs or inspects traffic before it reaches Anthropic.

For regulated environments, Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry let you run Claude Code against models hosted inside your own cloud account instead of Anthropic's. Billing, IAM policies and audit logs then sit in infrastructure your organization already controls. None of this is offline. It swaps a call to Anthropic for a call to your own AWS or GCP account, which helps with compliance and does not reduce the network dependency.

An LLM gateway is a third option: a service you run between Claude Code and the provider, mainly for centralized usage tracking, rate limits or authentication across a team. You point Claude Code at it with ANTHROPIC_BASE_URL, or the matching variable for Bedrock, Vertex or Foundry.

• HTTPS_PROXY and NO_PROXY route Claude Code's traffic through a corporate proxy.
• Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry run Claude inside your own cloud account.
• An LLM gateway centralizes auth and usage tracking. It still calls a model provider over the network.
• Run /status in a session to see the active provider, base URL and proxy before you blame the agent for a network problem.

Surviving a bad connection instead of pretending it's gone

A separate, more common problem is a connection that drops mid-task rather than being absent entirely: a laptop on flaky hotel wifi, a VPN that hiccups. Claude Code runs several idle-stream timers for exactly this. If no response headers arrive after a request, a first-byte deadline aborts the call, 180 seconds on the direct Anthropic API and 300 seconds through most other paths. If bytes stop arriving mid-stream, separate byte-level and event-level watchdogs catch that too, so a session fails fast and retries instead of hanging indefinitely.

That matters for how you plan work. A long agent run on an unreliable connection is going to hit retries sooner or later. Design tasks so a retried or restarted turn never leaves your repository half-edited: commit or stash in small steps rather than building up one giant uncommitted change and hoping the connection holds until it's done.

• Claude Code aborts a stalled stream rather than hanging forever, then retries.
• First-byte and byte-level watchdogs both run by default; you do not need to configure them to benefit.
• Commit in small steps so a dropped connection costs minutes, not hours, of redone work.

What actually runs locally, and why it's still worth controlling

Even though the model call leaves your machine, everything the agent does with the result happens locally: reading your repository, writing files, running your test suite, calling git. That local half is where a developer can set real boundaries, and it is worth doing regardless of your network setup, because a coding agent with your file permissions can read anything you can read.

This is also where a tool built around Claude Code adds value without touching the network question at all. A terminal built for running agents can confine what a session reads and writes, keep credentials out of the prompt, and show you what several agents are doing at once, while the actual reasoning still travels over the wire to Anthropic or your cloud account.

• The agent's file reads, file writes and shell commands all run on your machine.
• That local half is exactly where a folder boundary or a secrets vault earns its keep.
• None of this changes whether the model call itself needs a network connection.

How Forkbench supervises Claude Code on your Mac

Forkbench is a desktop app for running coding agents, including Claude Code, in real terminals on a Mac. Each session gets its own tab and its own Thread, with a live pulse driven by CPU and output rate, never a token count, so you can tell which agent is actually working and which one has stalled. A red needs-you flag appears with a count when Claude is blocked waiting on a decision only you can make.

A Thread can be locked to its own folders by the macOS kernel sandbox, so a Claude Code session confined to one Thread cannot read ~/.ssh, your other repositories or the rest of Documents. The Vault keeps API keys and tokens in your Keychain and lets Claude use one by name, so the value reaches the command that needs it without ever sitting in the prompt or the transcript.

State the limits plainly. None of this makes Claude Code work without a network connection. Forkbench supervises the local half of the session; the model call still goes to Anthropic or whichever cloud provider you have configured. The folder lock is opt-in and does not restrict the network, so a locked agent can still send out whatever it is allowed to read. An unpinned Vault key can still be read by the program that was run with it.

• Live pulse and a needs-you flag show which Claude Code session is working, stuck or waiting on you.
• Folder lock, opt-in, confines reads and writes to the Thread's folders, enforced by the macOS kernel.
• Vault: Claude uses a key by name. The value never reaches the prompt or the transcript.
• Limit: the folder lock does not restrict the network, and an unpinned key can still be read by the program it was run with.

A setup that holds up away from a reliable connection

Start by confirming what your network actually allows. Run claude --debug and check /status for the active provider, base URL and proxy, so you know exactly what Claude Code is trying to reach before you blame the agent for a network problem it did not cause.

If you're on a corporate network, ask whether Bedrock, Vertex or a gateway is already set up, rather than fighting a firewall rule by rule on your own. If you're just someone working from unreliable wifi, plan for retries instead of trying to prevent them: small commits, short tasks, and a tool that tells you the moment a session needs your input instead of leaving you to guess why it went quiet.

• Check /status before assuming a stall is the model's fault.
• Ask whether your organization already routes Claude Code through Bedrock, Vertex or a gateway.
• Keep tasks short and commits small so a dropped connection costs minutes, not hours.
• Use a live view of every session so a stalled agent does not sit unnoticed.

What this does not solve

No configuration here gets you a Claude agent that keeps reasoning with the wifi off. If your use case genuinely requires an agent that works with zero network access, a flight, a classified facility, air-gapped hardware, you want an agent built on an open-weight model you can run locally with something like Ollama or LM Studio, not Claude.

That is a real tradeoff, not a workaround. A local open model is usually smaller and weaker than Claude, in exchange for actually running without a network at all.

• A genuinely air-gapped setup needs a local open-weight model, not Claude.
• Local open models trade some capability for true offline operation.