Offline / Sovereignty Mode

The guarantee

When offline mode is active, BharatCode surfaces a single, unambiguous proof message at startup:

offline mode active: code will not leave this machine

That line is a promise the binary keeps mechanically. Rather than trusting a provider's data-handling policy, offline mode removes the ability to reach any non-local endpoint in the first place: remote model providers, remote tool servers, the web tools, and shell commands that shell out to a network client are all closed off before they can run.

Turning it on

There are two independent ways to enable offline mode — either is sufficient, and they compose. The first is the --offline flag, which applies to a single invocation of the TUI or a headless run:

$ bharatcode --offline$ bharatcode run --offline "summarize internal/config"

The second is the BHARATCODE_OFFLINE environment variable. Set it to a truthy value — 1, true, yes, or on (case-insensitive) — to force offline mode on for every BharatCode process in that environment, which is the right fit for a locked-down machine or a CI image:

$ export BHARATCODE_OFFLINE=1$ bharatcode

What offline mode blocks

Offline mode closes every direct path that could carry code off the machine. There are four enforcement points:

Non-localhost providers

Before the session starts, every enabled provider in your config is checked: its effective endpoint must resolve to a loopback host (localhost, a 127.x address, or ::1). Any provider that would dial a public API is rejected, and the error names every offender at once so you can fix them together. A disabled provider is ignored — it is never contacted, so it cannot leak anything. The check fails closed: a provider whose URL is missing or unparseable is treated as non-local and rejected.

Remote MCP servers

A remote MCP server is an egress channel just like a remote model: the agent's tool arguments — which can contain source code — are sent to wherever the server lives. So network-transport MCP servers (http, sse) must point at a loopback URL. A stdio server runs as a local child process over pipes and is always allowed. As with providers, disabled servers are skipped and the check fails closed on a missing or unparseable URL.

The web tools

The two network-egress tools — web_fetch and web_search — are withheld from the tool registry entirely. The agent does not see them, so there is no way for it to send a prompt or a snippet of code out through a tool call. Their absence, not a runtime refusal, is the guarantee.

Network-egress bash commands

The bash tool must not become an escape hatch around the guarantee, so offline mode refuses any command that invokes a known network-egress client before it can run. The blocked set is the dedicated network tools — curl, wget, scp, sftp, rsync, ssh, nc/netcat, socat, and similar — plus the network-contacting git verbs (git push, clone, fetch, pull). The matcher is quote-aware and sees through wrappers, so sudo curl … or timeout 5 curl … is caught just like a bare curl.

Running fully local

Because offline mode rejects non-localhost providers, you pair it with a model server running on your own machine. The two zero-config local options are Ollama (default http://localhost:11434) and LM Studio (default http://localhost:1234/v1). Point a provider at the local endpoint:

{  "providers": [    {      "name": "local",      "type": "ollama",      "base_url": "http://localhost:11434"    }  ]}

Then launch with the flag — the agent reads, edits, runs tests, and reasons over your repository with a model that never leaves the box:

$ bharatcode --offline

Interactions with other commands

Offline mode also disables BharatCode's own network operations, since probing or downloading is itself egress:

• bharatcode update (and --apply) is a no-op — it prints the offline banner and exits without contacting GitHub.
• The startup auto-update check is skipped entirely while offline.