{"slug": "running-lm-studio-locally-doesn-t-mean-it-never-connects-out", "title": "Running LM Studio Locally Doesn't Mean It Never Connects Out", "summary": "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.", "body_md": "When we say **“local LLM,”** it is easy to mentally translate that into:\n\nEverything stays inside the PC.\n\nFor inference, that can be true.\n\nBut the application running the model is still an application with network-capable features.\n\nLM Studio, for example, may need connectivity for things such as:\n\nIt can also expose a local API server, connect to MCP servers, enable CORS, or serve the API to other devices on the LAN.\n\nNone of those features are inherently bad.\n\nBut I wanted a much narrower environment:\n\n**one approved model, local inference, and as little external connectivity as possible.**\n\nSo I treated “local execution” and “network isolation” as two separate problems.\n\nFor normal use, I wanted this:\n\n```\nLM Studio\n   |\n   +---- 127.0.0.1 / localhost ---- allowed\n   |\n   +---- LAN ----------------------- blocked\n   |\n   +---- Internet ------------------ blocked\n```\n\nThe important part is the loopback connection.\n\nBlocking everything blindly can also break communication that stays entirely inside the machine.\n\nSo the rule became:\n\n**deny external communication, but deliberately preserve loopback.**\n\nLM Studio already provides useful settings.\n\nFor my baseline I disable features I do not need:\n\n`mcp.json`\n\nI also keep the API server off because I do not need it for this evaluation.\n\nAnd my `mcp.json`\n\nis intentionally boring:\n\n```\n{\n  \"mcpServers\": {}\n}\n```\n\nBut I do not want the security of the environment to depend entirely on application settings.\n\nSettings can be changed.\n\nTheir internal representation can also change between versions.\n\nSo I use two layers:\n\n```\nLM Studio settings\n        +\nOS network controls\n```\n\nThe first expresses the intended configuration.\n\nThe second enforces the boundary.\n\nThis was probably the most useful design decision.\n\nLM Studio needs the network while preparing the machine.\n\nSo I split operation into two phases.\n\nNetwork access is temporarily available for things that genuinely require it:\n\n```\nInstall LM Studio\n        ↓\nDownload the approved runtime\n        ↓\nDownload the approved model\n        ↓\nVerify the files\n```\n\nAfter that, normal use does not need model discovery or downloads.\n\nThe environment becomes much smaller:\n\n```\nStart LM Studio\n        ↓\nRestore the hardened configuration\n        ↓\nCheck MCP configuration\n        ↓\nCheck network restrictions\n        ↓\nUnload previously loaded models\n        ↓\nLoad only the approved model\n        ↓\nRun locally\n```\n\nThis avoids trying to make installation and daily operation obey the same network policy.\n\nThey are different states.\n\nAnother thing I did not want was:\n\n“LM Studio is approved, therefore any model inside LM Studio is approved.”\n\nThose are two different decisions.\n\nAt startup I first unload existing models:\n\n```\nlms unload --all\n```\n\nThen I load the model selected for the evaluation:\n\n```\nlms load <approved-model> \\\n  --context-length 8192 \\\n  --identifier approved-model\n```\n\nThe actual startup wrapper also verifies that the expected model is available before continuing.\n\nIf the expected state cannot be established, startup should fail rather than quietly falling back to something else.\n\nThat is a small change, but it makes the environment much more reproducible.\n\nMy current use case does not require it, so I leave it off.\n\nBut LM Studio's CLI supports explicitly binding the server to loopback:\n\n```\nlms server start \\\n  --bind 127.0.0.1 \\\n  --port 1234\n```\n\nThat is very different from:\n\n```\nlms server start --bind 0.0.0.0\n```\n\nThe first stays on localhost.\n\nThe second makes the server reachable beyond localhost and changes the security boundary significantly.\n\nFor a controlled local evaluation, I would not expose it unless there is a concrete reason to do so.\n\nA configuration file saying “disabled” is not enough.\n\nI want to observe what actually happens.\n\nSo the evaluation includes checks such as:\n\nThe distinction matters:\n\n```\nconfiguration → what should happen\nverification  → what actually happened\n```\n\nFor this kind of environment, I want both.\n\nThis experiment changed how I think about the word **local**.\n\nA local LLM tells me where the model inference runs.\n\nIt does not automatically define every network behavior of the application surrounding that model.\n\nSo my final model is:\n\n```\nLocal inference\n      ≠\nNetwork isolation\n```\n\nIf I care about both, I need to design for both.\n\nLM Studio already works well offline once the required model and runtime are available.\n\nWhat I added was a smaller operational boundary around it:\n\n**prepare while connected, then run with the outside closed and only the communication that must stay inside the machine deliberately preserved.**\n\nThe full implementation and notes are available in the original Legacy Tools article.", "url": "https://wpnews.pro/news/running-lm-studio-locally-doesn-t-mean-it-never-connects-out", "canonical_source": "https://dev.to/k-wada/running-lm-studio-locally-doesnt-mean-it-never-connects-out-keb", "published_at": "2026-08-20 07:01:51+00:00", "updated_at": "2026-08-20 07:13:41.877803+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-safety"], "entities": ["LM Studio"], "alternates": {"html": "https://wpnews.pro/news/running-lm-studio-locally-doesn-t-mean-it-never-connects-out", "markdown": "https://wpnews.pro/news/running-lm-studio-locally-doesn-t-mean-it-never-connects-out.md", "text": "https://wpnews.pro/news/running-lm-studio-locally-doesn-t-mean-it-never-connects-out.txt", "jsonld": "https://wpnews.pro/news/running-lm-studio-locally-doesn-t-mean-it-never-connects-out.jsonld"}}