Running LM Studio Locally Doesn't Mean It Never Connects Out

A developer detailed a method for running LM Studio with strict network isolation, treating local execution and network connectivity as separate concerns. The approach combines application settings with OS-level controls to block external communication while preserving loopback, and includes a startup wrapper that unloads all models and loads only an approved one, with verification steps to ensure the intended configuration is enforced.

When we say “local LLM,” it is easy to mentally translate that into: Everything stays inside the PC. For inference, that can be true. But the application running the model is still an application with network-capable features. LM Studio, for example, may need connectivity for things such as: It can also expose a local API server, connect to MCP servers, enable CORS, or serve the API to other devices on the LAN. None of those features are inherently bad. But I wanted a much narrower environment: one approved model, local inference, and as little external connectivity as possible. So I treated “local execution” and “network isolation” as two separate problems. For normal use, I wanted this: LM Studio | +---- 127.0.0.1 / localhost ---- allowed | +---- LAN ----------------------- blocked | +---- Internet ------------------ blocked The important part is the loopback connection. Blocking everything blindly can also break communication that stays entirely inside the machine. So the rule became: deny external communication, but deliberately preserve loopback. LM Studio already provides useful settings. For my baseline I disable features I do not need: mcp.json I also keep the API server off because I do not need it for this evaluation. And my mcp.json is intentionally boring: { "mcpServers": {} } But I do not want the security of the environment to depend entirely on application settings. Settings can be changed. Their internal representation can also change between versions. So I use two layers: LM Studio settings + OS network controls The first expresses the intended configuration. The second enforces the boundary. This was probably the most useful design decision. LM Studio needs the network while preparing the machine. So I split operation into two phases. Network access is temporarily available for things that genuinely require it: Install LM Studio ↓ Download the approved runtime ↓ Download the approved model ↓ Verify the files After that, normal use does not need model discovery or downloads. The environment becomes much smaller: Start LM Studio ↓ Restore the hardened configuration ↓ Check MCP configuration ↓ Check network restrictions ↓ Unload previously loaded models ↓ Load only the approved model ↓ Run locally This avoids trying to make installation and daily operation obey the same network policy. They are different states. Another thing I did not want was: “LM Studio is approved, therefore any model inside LM Studio is approved.” Those are two different decisions. At startup I first unload existing models: lms unload --all Then I load the model selected for the evaluation: lms load <approved-model \ --context-length 8192 \ --identifier approved-model The actual startup wrapper also verifies that the expected model is available before continuing. If the expected state cannot be established, startup should fail rather than quietly falling back to something else. That is a small change, but it makes the environment much more reproducible. My current use case does not require it, so I leave it off. But LM Studio's CLI supports explicitly binding the server to loopback: lms server start \ --bind 127.0.0.1 \ --port 1234 That is very different from: lms server start --bind 0.0.0.0 The first stays on localhost. The second makes the server reachable beyond localhost and changes the security boundary significantly. For a controlled local evaluation, I would not expose it unless there is a concrete reason to do so. A configuration file saying “disabled” is not enough. I want to observe what actually happens. So the evaluation includes checks such as: The distinction matters: configuration → what should happen verification → what actually happened For this kind of environment, I want both. This experiment changed how I think about the word local . A local LLM tells me where the model inference runs. It does not automatically define every network behavior of the application surrounding that model. So my final model is: Local inference ≠ Network isolation If I care about both, I need to design for both. LM Studio already works well offline once the required model and runtime are available. What I added was a smaller operational boundary around it: prepare while connected, then run with the outside closed and only the communication that must stay inside the machine deliberately preserved. The full implementation and notes are available in the original Legacy Tools article.