Air-gapped AI coding in 2026: a developer setup guide

Most AI coding tools describe themselves as "local" or "private" while still making outbound connections: telemetry pings, license checks, CDN fetches for UI assets, or automatic update calls. For developers in regulated environments, security-conscious teams, or anyone who takes data ownership seriously, "local" is not good enough. Air-gapped AI coding means zero bytes leave the machine, enforced at the network level, not just by a privacy toggle.

This guide covers what air-gapping actually involves, the five network vectors you need to block, and how to set it up in practice.

Air-gapped vs. offline vs. local-first

These three terms get used interchangeably, but they mean different things:

• Local-first: the model runs on your machine by default, but the app may still make outbound connections for other purposes (telemetry, updates, license validation).
• Offline: the app can function without an internet connection, but it may not be enforced. A toggle exists; you trust the toggle.
• Air-gapped: all network egress is blocked at the OS level, independently of the application. The app cannot phone home even if a bug or update resets its own settings. This is the stricter standard.

For casual use, local-first is fine. For any environment with compliance requirements, air-gapped is the correct baseline.

Who actually needs this (not just enterprises)

Air-gapped AI is not only for CMMC-compliant contractors and HIPAA-covered teams. Individual developers have real reasons to want it:

• You work on client code under NDA and your contract prohibits sending code to third-party servers.
• You are building a security tool or vulnerability research project and do not want your payloads or PoC code indexed by an AI provider.
• You work on a machine that is sometimes on an unsecured network, and you want the same behavior regardless of where you connect.
• You simply want to know for certain that your code does not leave your machine, without having to trust a privacy policy you cannot audit.

The five network egress vectors to block

A proper air-gap implementation addresses every path that data can travel outbound. The five vectors that matter for an AI coding environment are:

1. Model API calls. The model runner itself (Ollama, LM Studio, llama.cpp) only listens on localhost by default, but verify this. An outbound API call to a hosted model breaks the air gap immediately.
2. Telemetry. Most Electron apps include a telemetry collector. These are usually batched and sent on a schedule, not immediately, so they can slip past a quick network test.
3. Update checks. Automatic update pings often reveal your IP, app version, and platform to the vendor's update server. Disable in-app auto-updates or block the update domain at the firewall level.
4. WebView asset fetches. If the IDE uses a WebView (common in Electron apps), a bug or misconfiguration can cause it to fetch fonts, analytics scripts, or CDN assets from the internet during rendering.
5. Extension and plugin calls. Any extensions you install inside the IDE have their own network behavior. A VS Code extension that tracks usage events is a real egress vector even if the host IDE is configured correctly.

The only way to guarantee all five are blocked is to enforce at the OS level and verify with an audit log.

Setup: Bodega One air-gap mode

Bodega One air-gap mode blocks all five vectors through nine enforcement layers: OS firewall rules, process spawn controls, telemetry stripping, DNS blocking, WebView network policy, and an outbound connection audit log. The audit log is the part that matters for verification: it records every connection the app process attempts, successful or blocked, in a plain-text file you can inspect.

1. Install Ollama and pull your model. Recommended for most hardware: ollama pull qwen2.5-coder:14b-instruct-q4_K_M. For 16 GB VRAM or more, use ollama pull qwen2.5-coder:32b-instruct-q4_K_M. Check the Ollama setup guide for model-specific notes.
2. Install Bodega One and complete initial setup. Go to Settings → Providers, select Ollama, verify the base URL is http://localhost:11434.
3. Enable air-gap mode. Settings → Privacy → Air-gap Mode. This activates the OS-level firewall rules and disables the WebView network policy.
4. Disconnect from the internet. On macOS or Linux, you can also run sudo pfctl -e (macOS) or use ufw (Linux) as an independent enforcement layer on top of the in-app rules.
5. Verify with the audit log. Settings → Air-gap → Audit Log. After running an agent task, confirm the log shows zero external connection attempts. Local calls to 127.0.0.1:11434 (Ollama) are expected and are not egress.

Free alternative: Continue.dev + OS firewall

If you want a free setup, Continue.dev with Ollama plus a host-level firewall rule is a viable approach. It does not give you an audit log, and you are responsible for verifying every component in the chain, but it works.

• Install Ollama and pull a model locally.
• Install Continue.dev in VS Code. Configure it to use Ollama at localhost:11434.
• Disable VS Code telemetry (telemetry.telemetryLevel: "off") and auto-updates (update.mode: "none").
• Add an outbound firewall rule that blocks all traffic from the VS Code process except to 127.0.0.1. On Linux: ufw deny out from any to ! 127.0.0.1 app "code" (adjust per your distro's ufw syntax).
• Verify with sudo lsof -i -n -P | grep code | grep ESTABLISHED after a few minutes of use.

The main limitation is that Continue.dev does not have a built-in agentic loop, so it works for chat and completions but not for autonomous multi-step tasks.

Verifying your air gap independently

Do not trust the app's own report. Verify with OS-level tools:

• macOS: Little Snitch gives a real-time map of every outbound connection by process. Run the IDE for 30 minutes, run an agent task, and review the connection log.
• Linux: ss -tupn lists all active connections with process names. Run before and after a task to catch any new external connections.
• Windows: netstat -bano from an elevated command prompt shows all connections with the owning executable name.
• All platforms: Wireshark on the network interface will catch anything the above tools miss, including DNS queries.

DNS queries are an often-overlooked egress vector. An app can leak hostnames even if the TCP connection is blocked. Bodega One's air-gap mode blocks DNS resolution for the app process as one of its nine layers.

Model recommendations for air-gapped coding

You need models that are small enough to fit in your VRAM but capable enough for real coding tasks. Pull these with Ollama before disconnecting:

The Qwen2.5-Coder-32B at Q4 is the gold standard for local coding if your hardware supports it. Pull all models you might need before going offline. Once the network is disconnected, Ollama will only serve what is already in its local library.

Is full air-gapping worth it for your use case?

For most individual developers, a local-first setup with Ollama and no cloud models is sufficient. The data stays on your machine, and the risk profile is low.

Full air-gapping with OS-level enforcement makes sense if you are working under a compliance requirement, handling genuinely sensitive code, or want provable guarantees rather than trust-based ones. The air-gapped AI for regulated industries guide covers the enterprise compliance angle in more depth if that is your context.

For the simplest verified air-gap setup: install Bodega One, enable air-gap mode, pull a model in Ollama before disconnecting, and check the audit log after your first task. The whole process takes under 20 minutes. Join the waitlist for the May 2026 beta.