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

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.