Hey folks. I've been reviewing our internal deployment guidelines for Claude Code and a common question keeps coming up from teams in regulated environments.
Is there a way to run Claude Code in a strictly offline mode? Specifically, a CLI flag or environment variable that would prevent any network calls during a session—no package index checks, no API calls, no fetching remote content. We're looking for a hard boundary, not just a guideline.
I know we can sandbox the environment itself, but for certain compliance needs (think air-gapped research, handling sensitive IP, or specific privacy frameworks), we need the tool itself to be explicitly constrained at runtime. A runtime flag would make auditing and policy enforcement much cleaner.
If this doesn't exist yet, it's a feature request I'd strongly advocate for. The ability to declaratively disable network egress would be a huge win for security-sensitive deployments. Anyone else running into this, or have workarounds to share?
Sam
That's a really good question. I'm also curious if there's a built-in way. I run a lot of tools in Docker, and my usual workaround is to start the container with --network=none. But that's a system-level block, not a flag for the tool itself.
Would a tool-level flag actually be more secure, or is the system-level sandbox enough? I'm never sure about the compliance angle.
Good question on the system-level vs tool-level block. The container approach is definitely more comprehensive, but I've seen cases where a tool-level flag still matters for compliance. Sometimes you need a verifiable, *runtime* statement from the tool itself, not just an environment assumption.
For auditing, you might have a requirement that the tool logs its own operating mode. A `--offline` flag could trigger a startup log entry that's captured in your SIEM, proving the constraint was applied at the application layer. That's sometimes needed to satisfy specific control frameworks.
That said, I'd still combine both. Use `--network=none` *and* push for the tool flag. Defense in depth, plus it covers any subprocesses or libraries that might try to bypass a user-space flag.
Defend the perimeter, control the API.
Great question, and I completely agree on the need for a declarative runtime constraint. You've nailed the exact use case: for frameworks like SOC 2 or ISO 27001, you need the application to *attest* to its own operating mode for audit trails. A container sandbox is an environmental control, but a CLI flag becomes an application-level control you can cite in your evidence.
A workaround I've seen is using a wrapper script that sets a custom environment variable and then calls the CLI. The script can log the variable being set, which gives you that runtime log entry. It's not as clean as a native flag, but it creates a more auditable event than just assuming a container's network policy.
Your feature request would directly support several common privacy framework requirements. I'd add that the flag should ideally output a clear, machine-readable log line at startup, something like "OPERATING_MODE: NETWORK_ACCESS_DISABLED" for easy parsing by your compliance tooling.
Audit-ready or go home.