Installing SentinelX on Linux, macOS, and Windows

One agent, three platforms. A clear, copy-paste walkthrough to get a host enrolled and answering to your LLM in a couple of minutes.

SentinelX runs a small agent on each host you want to operate from Claude.ai or ChatGPT. The agent opens a single outbound connection to the hub — no inbound ports, no port-forwarding — and only ever does what your config allows. Installing it is one command on Linux or macOS, and a short PowerShell script on Windows. Here is the whole thing, per platform.

The installer does the same job everywhere: it builds a virtualenv, registers the agent as a service so it survives reboots, writes a starter config you can tighten later, and walks you through a browser sign-in that binds the host to your account.

Before you start

• You sign in with Google or GitHub during enrollment — that is your account on the hub at mcp.sentinelx.app.
• Linux: root, plus git, python3, and systemd — standard on any modern distro.
• macOS: nothing extra; the installer fetches Python via uv.
• Windows: Python 3.12+ and git on PATH (from python.org and git-scm.com).

Linux

One command, as root. It auto-detects your distro and sets the agent up under systemd:

curl -fsSL https://get.sentinelx.app | bash

The agent runs as an unprivileged sentinelx user — never root — and its reach is limited to the allowlist in /etc/sentinelx/config.yaml. When the script reaches enrollment it prints a URL: open it, sign in, copy the token it shows, and paste it back into the terminal.

macOS

The exact same one-liner — it detects macOS and installs under launchd:

curl -fsSL https://get.sentinelx.app | bash

On a Mac the agent installs per-user and is supervised by launchd, so it comes back after a reboot or logout. Enrollment is identical: open the URL, sign in, paste the token.

Windows

Windows uses a PowerShell installer instead of curl | bash. Make sure Python 3.12+ and git are on your PATH, then choose one of two modes.

Service install (recommended)

Runs as a Windows service under LocalSystem and starts at boot — the Windows analogue of systemd or launchd. Run it in an elevated PowerShell:

iwr -useb https://get.sentinelx.app/install.ps1 -OutFile "$env:TEMP\sx.ps1"
powershell -ExecutionPolicy Bypass -File "$env:TEMP\sx.ps1"

Per-user install (no admin)

No administrator rights? Add -User. The agent registers a per-user Scheduled Task that runs windowless at logon, as you — the right fit for locked-down or corporate machines:

iwr -useb https://get.sentinelx.app/install.ps1 -OutFile "$env:TEMP\sx.ps1"
powershell -ExecutionPolicy Bypass -File "$env:TEMP\sx.ps1" -User

On a network that blocks PyPI, add -Bundle <zip-or-url> to install from the offline wheel bundle attached to the latest release. Behind a TLS-inspecting proxy, the agent verifies the hub certificate against the OS trust store, so your company CA is accepted without weakening verification.

Connect your LLM

Once a host is enrolled, point your assistant at the hub. You do this once per account, not per host:

• ChatGPT: install SentinelX from the app directory, click Connect, and sign in with the same account. No URL to copy.
• Claude.ai: Settings → Connectors → Add custom connector → https://mcp.sentinelx.app/mcp/mcp, then authorize with the same account.

Verify it works

Ask your assistant something harmless:

"List my SentinelX servers." · "Show uptime and disk usage on my-vps."

The host should come back by its host_id or hostname. Add more machines by running the same install command on each; you can give any of them a friendly label later. See the whole fleet — and what is online — at mcp.sentinelx.app/dashboard.

What the agent can — and cannot — do

Nothing you have not allowed. The starter config the installer writes is deny-by-default: the LLM can only run the commands, manage the services, and edit the files you list in config.yaml. Widen it when you need more, narrow it when you want less. The allowlist — not the model's good behavior — is the real trust boundary.