security: default Studio host to 127.0.0.1 and prompt before auto-start#4864
security: default Studio host to 127.0.0.1 and prompt before auto-start#4864Bedrovelsen wants to merge 4 commits into
Conversation
Closes unslothai#4684. Previously Unsloth Studio bound to 0.0.0.0 (all interfaces) by default and the installer silently auto-started a server at the end of install, contradicting the documented "privacy first / 100% offline and locally" guarantee and exposing the service on the network without user consent. Changes: - studio/backend/run.py: change run_server() default host to 127.0.0.1; extract argparse setup into _make_argument_parser() for testability - unsloth_cli/commands/studio.py: change typer.Option default to 127.0.0.1 - install.sh: remove -H 0.0.0.0 from generated launch-studio.sh launcher template; replace silent auto-start with a [Y/n] prompt - install.ps1: replace silent auto-start with a Read-Host [Y/n] prompt - README.md: simplify launch examples to `unsloth studio` (no -H flag); note that -H 0.0.0.0 is available for cloud/network use Users who need all-interface binding (cloud VMs, LAN sharing) can still pass -H 0.0.0.0 explicitly. No other logic was changed: _is_port_free(), startup_banner, and health-check paths all already handle 127.0.0.1 correctly. Tests (TDD — written before implementation): - studio/backend/tests/test_host_defaults.py: AST inspection of run_server() parameter default and argparse --host default - tests/studio/test_cli_studio_defaults.py: AST inspection of typer.Option default for studio_default() --host parameter - tests/sh/test_install_host_defaults.sh: static analysis of installer scripts and README launch section https://claude.ai/code/session_012umxRmBdeDV5U7Xhm1utu6
Bedrovelsen
requested review from
danielhanchen and
rolandtannous
as code owners
for more information, see https://pre-commit.ci
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request improves the security posture of Unsloth Studio by changing the default network binding from 0.0.0.0 (all interfaces) to 127.0.0.1 (loopback). This change is applied across the CLI, backend server, and installation scripts, with accompanying automated tests to verify the new defaults. I have identified an inconsistency in the install.ps1 script where the desktop shortcut launcher still contains the old hardcoded 0.0.0.0 binding, which should be updated to maintain consistent security defaults.
| } else { | ||
| step "launch" "to start later, run:" | ||
| substep "unsloth studio" | ||
| substep "(add -H 0.0.0.0 to allow network / cloud access)" |
There was a problem hiding this comment.
The manual command hint correctly suggests adding -H 0.0.0.0 for network access. However, there is an inconsistency in the New-StudioShortcuts function (specifically the $launcherContent here-string at line 381), which still has -H 0.0.0.0 hardcoded in the $studioCommand variable. This should be updated to match the new security defaults so that the desktop shortcut also binds to 127.0.0.1 by default, ensuring consistency with the changes made to the install.sh launcher template.
|
|
superseded by #5267 . closing this one. thank you for the effort |
3 participants
Closes #4684.
Previously Unsloth Studio bound to 0.0.0.0 (all interfaces) by default and the installer silently auto-started a server at the end of install, contradicting the documented "privacy first / 100% offline and locally" guarantee and exposing the service on the network without user consent.
Changes:
unsloth studio(no -H flag); note that -H 0.0.0.0 is available for cloud/network useUsers who need all-interface binding (cloud VMs, LAN sharing) can still pass -H 0.0.0.0 explicitly. No other logic was changed: _is_port_free(), startup_banner, and health-check paths all already handle 127.0.0.1 correctly.
Tests (TDD — written before implementation):
https://claude.ai/code/session_012umxRmBdeDV5U7Xhm1utu6