SentinelX
Manage Linux, Mac & Windows
- Category
- Developer Tools
- Primary Subcategory
- Cloud Infrastructure Management
Integration details
Description
SentinelX lets you manage your Linux, macOS, and Windows servers from ChatGPT — no SSH required. Install a small open-source agent on any Linux, macOS, or Windows host, and ChatGPT can run inspection commands, manage services (systemd, launchd, or Windows services), read/search/edit files, run scripts, upload files, and call out to integrations like Cloudflare DNS, Resend, and Telegram. Every action is constrained by a per-host allowlist that you control. The agent only runs commands and services you've explicitly declared safe, rejects anything outside the policy at the agent boundary, and your OS's file permissions still apply on top. You can connect multiple hosts and label them however you want. Typical uses: check uptime and disk space, restart services, tail logs, edit config files, run quick scripts, manage DNS records, send notifications. The agent is open source on GitHub (github.com/pensados/sentinelx-cloud-core). Authentication uses OAuth 2.0 with PKCE and Dynamic Client Registration, scoped per user.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Cloud Infrastructure Management
- Secondary Subcategories
- None listed
- Brand
- SentinelX
- Access
- Account required
- First tracked
- 2026-07-21
- Tool count
- 49
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Get alerts for SentinelX
Get updates when SentinelX’s Discoverability Score or category rank changes.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like

Competing in ChatGPT Cloud Infrastructure Management
View Category49 tools agents can invoke
Run the edit using files previously staged via sentinel_edit_upload_file.
sentinel_edit_upload_complete
Begin a chunked upload. Returns an `upload_id` to use in upload_chunk and upload_complete. `total_size` is optional; if provided, the agent verifies the assembled file matches.
sentinel_upload_init
Initialize an edit upload session. Returns an `upload_id` to use in the follow-up calls (sentinel_edit_upload_file, sentinel_edit_upload_complete).
sentinel_edit_upload_init
Talk to a tool on the host that already speaks a structured protocol. Use this instead of `sentinel_exec` when the target exposes a socket or JSON-RPC endpoint, because the answer comes back as data rather than as text meant for a terminal. Docker is the common case: `State` is the machine value "running" rather than something to infer from "Up 7 hours (healthy)", and ports are a structured list rather than a comma-laden string. Only endpoints and actions the host has declared are reachable. The host's config is the allowlist and neither the model nor the hub can widen it.
sentinel_local_api
Change the mode bits of a path on the target host. The path must resolve under an `rw` file_ops entry.
sentinel_chmod
Change the owner and/or group of a path on the target host. The path must resolve under an `rw` file_ops entry. At least one of `owner`/`group` is required. Note: chown to a different owner normally requires root. The agent typically runs as a non-root service user, so this will usually fail with `permission_denied` — the agent reports that explicitly rather than pretending it worked. It is included for completeness and for the cases where the agent IS privileged.
sentinel_chown
Read the notifications inbox: background job results AND operator broadcasts (product/ops announcements — updates, maintenance, features).
notifications
Remove the user's default host preference. After this, tool calls without an explicit host_id will fall back to the standard behavior: auto-route if only one host is connected, or ambiguous_host error if multiple are connected. Returns: {"ok": True, "removed": true|false}. removed=false means no default was set in the first place (no-op, not an error — the tool is idempotent).
sentinel_clear_default_host
Simple health check (does not call SentinelX core internals).
sentinel_ping
Copy a file or directory on the target host. BOTH `src` and `dst` must resolve under an `rw` file_ops entry. The destination is gated exactly like the source — otherwise copy would be an exfiltration primitive (read from an rw path, write the bytes anywhere). Directories are copied recursively.
sentinel_copy
Create a new DNS record in a Cloudflare zone. Common types: A (IPv4), AAAA (IPv6), CNAME (alias), TXT (text), MX (mail). The `proxied` flag only applies to A/AAAA/CNAME and routes traffic through Cloudflare's edge. NOTE on TTL and proxied: if proxied=True, Cloudflare overrides the ttl to 1 ("auto") regardless of what you pass. This is documented Cloudflare behavior, not a bug. For non-proxied records, ttl can be 1 (auto) or 60..86400 seconds.
cloudflare_dns_create_record
Delete a DNS record from a Cloudflare zone. Destructive: the record is gone immediately and the deletion propagates through Cloudflare's network in seconds. Use cloudflare_dns_list_records first to confirm you have the right record_id.
cloudflare_dns_delete_record
Delete a file or (with recursive=true) a directory. The path must resolve under an `rw` file_ops entry. The agent ALWAYS takes a backup before destroying anything: a file is copied to a sibling `.bak.<timestamp>`, a directory is archived to a sibling `.bak.<timestamp>.tar.gz`. If the backup cannot be made the delete is refused (`backup_failed`) — nothing is destroyed without a recovery path. Deleting a directory requires `recursive=true` explicitly. Without it, a directory is rejected with `is_directory`. This makes accidental `rm -rf`-shaped mistakes impossible to trigger by a single confused call.
sentinel_delete
Edit a file on the connected host using safe, structured operations. Modes: - replace literal old -> new_text - regex pattern -> new_text - replace-block start_marker..end_marker -> new_text - append append new_text to file - prepend prepend new_text to file - write overwrite file with new_text For large content use the chunked variant: sentinel_edit_upload_init, sentinel_edit_upload_file, sentinel_edit_upload_complete. Security: `path` must resolve under a file_ops entry whose access is `rw` in the agent's config (the unified r/rw path model). A path that is only readable (access: r), or outside the allowlist, or that escapes it via `..`/symlink, is rejected with path_not_allowed — edit is a mutation and is gated exactly like move/copy/delete. This is enforced agent-side, after canonicalizing symlinks.
sentinel_edit
Return the user's currently-configured default host (if any). The response carries both the stored host_id AND a flag indicating whether that host is currently connected, so the caller knows whether tool calls without explicit host_id will succeed. Returns: {"ok": True, "default_host_id": "<id> or null", "is_connected": true|false|null} is_connected is null when no default is set.
sentinel_get_default_host
Inspect Cloudflare security configuration for a zone or account. Read-only. Use this to answer "why is this traffic being blocked" without turning protection off: list the rulesets, read the rules inside one, and look at what actually got blocked.
cloudflare_control
List DNS records in a Cloudflare zone, optionally filtered. Use this to inspect existing records and to get the record `id` values needed by update_record and delete_record. Returns up to 100 records per call; if a zone has more, narrow down with the `type` or `name` filters.
cloudflare_dns_list_records
List every Cloudflare zone the saved token has access to. Use this first to discover zone IDs before listing or modifying records. The result includes each zone's id, name, status, and whether it's paused.
cloudflare_dns_list_zones
List entries in a directory on the target host. Output is structured (each entry has name/type/size/mtime), unlike sentinel_exec("ls -la") which returns opaque text. Always skips common noise directories (.git, __pycache__, node_modules, .venv, .pytest_cache, dist, build, etc.) regardless of show_hidden.
sentinel_list
List the saved integrations for the calling user. Use this when you need to know which integrations are available before calling a provider tool (telegram_send_message, resend_send_email, cloudflare_dns_*). All those tools take an `integration_name`; this is how to discover the valid names. Returns: { "ok": true, "items": [ { "name": "<user-chosen alias>", "provider": "cloudflare" | "telegram" | "resend", "created_at": "<ISO8601>" }, ... ], "count": <int> } The returned data deliberately does NOT include each integration's metadata (e.g. Telegram default_chat_id, Resend default_from) nor the encrypted credentials. Those are managed exclusively from the dashboard UI by the authenticated user, and the LLM cannot read or modify them via tools. If the user has no integrations, returns an empty list with count zero — not an error.
list_integrations
List the authenticated user's hosts: connected, offline and disabled. Each host entry includes: - host_id: stable unique id, generated at install time - hostname: system hostname reported by the agent at handshake - label: user-defined alias (null if none set; see sentinel_set_host_label) - session_id: internal session identifier (null for a host currently served by another hub worker) - connected_at: ISO timestamp of when the agent connected - agent_version: version reported by the agent - capabilities: ops the agent supports - operational: whether this host may currently RUN operations. A host that is connected but beyond the plan's active-host limit is listed with operational=false plus a "status" and "note" explaining why; tool calls routed to it return upgrade_required until a slot frees (disconnect/disable another host) or the plan is upgraded. The top-level "slots" block summarises the plan: limit, how many hosts hold an active slot, how many are parked, and how many slots are available. Other tools' `host_id` parameter accepts any of host_id, label, or hostname. Resolution priority is exact host_id -> label -> hostname. Enrolled hosts that are NOT connected are not part of hosts/count; they are listed apart, so a missing host is never mistaken for a deleted one: - offline: enrolled, currently disconnected, with last_connected_at. It moves back into hosts on its own when its agent reconnects. - disabled: refused at connect, with disabled_at and disabled_by ("user": disabled from the dashboard, re-enable it there; "admin": disabled by SentinelX support). There is no tool to re-enable a host. Operations cannot target offline or disabled hosts. Each group holds at most 20 entries, most recent first; offline_total / disabled_total appear when there are more. Returns {"ok": true, "hosts": [...], "count": N, "slots": {...}, "offline": [...], "disabled": [...]}; offline and disabled only when non-empty.
sentinel_list_hosts
Manage the lifecycle of cloud VMs through a saved compute integration. A single tool with an `operation` selector. Which cloud is driven comes from the integration's saved metadata.driver (currently 'digitalocean').
compute
Mint a short-lived REST API key and return it with a ready-to-use contract. Use this when a task is better done as a batch/aggregation loop than as many separate MCP calls -- e.g. grep a huge log and return only a count, check a metric across N hosts and report only the outliers, or a fetch->filter-> summarize pipeline. Mint a key, then curl ``POST {base_url}/op`` from your sandbox; only the final summary needs to re-enter your context. The key carries YOUR access, scoped down and short-lived. It is never more than you already have over MCP: every op still passes the target agent's allowlist, and every call is audited exactly like an MCP call. Treat it as a secret -- anyone holding it has that access until it expires.
sentinel_request_api_key
Move or rename a file or directory on the target host. BOTH `src` and `dst` must resolve under a file_ops entry whose access is `rw` in the agent's config. Resolving happens after canonicalizing symlinks, so `..` traversal and symlink-escape are rejected. You cannot move data out of a writable subtree into a location the operator didn't declare.
sentinel_move
Persist and resume operational work across AI chats, sessions and models. Use this primitive for meaningful multi-step work that may continue later, before a handoff, when pending work remains, or when the user explicitly wants a checkpoint. Save concise operational state, not transcripts or secrets. Canonical IDs look like ``sentinelx_context_sxc_7K3M9Q2F``; ``sxc_7K3M9Q2F`` is accepted as shorthand. Operations: - ``save`` creates or checkpoints a context. New contexts require data.title, data.objective and data.summary. Each save creates a new revision; base_revision provides optimistic concurrency. - ``resume`` restores latest state (or options.revision). Default options.detail="summary" keeps token use small; use "full" when needed. Archived contexts remain read-only unless options.reactivate=true. - ``status`` reports the SXC currently bound to this conversation. - ``list`` returns compact context metadata with optional filters. - ``search`` performs deterministic keyword/tag search over saved state. - ``archive`` keeps a context searchable but removes it from normal active listings and clears active conversation bindings. - ``delete`` permanently removes Hub state and revisions; confirm=true is mandatory. Prefer archive for normal lifecycle cleanup. - ``settings`` gets/updates continuity preferences in options. V1 defaults to auto_save="suggest" and md_mode="off". - ``export_md`` returns a Markdown representation; it never writes files. Context relationships are lightweight links. To create a subcontext/fork, create a normal SXC with data.parent_context_id pointing at the parent. data.related_context_ids links peer contexts; no archive/delete cascades. Useful filters: status, host, workspace, tag/tags, tag_mode="and|or", task_group, parent_context_id, updated_after, updated_before, include_archived. Useful options: detail="summary|full", revision, limit, auto_save, md_mode. A resumed context restores knowledge, not authorization. Revalidate live host/service/Git/job state and any human approval before acting.
sentinel_context
One-call deterministic project/repository orientation. Aggregates git + filesystem facts into a single bounded response so you don't need several read/list/search/exec(git ...) round-trips to orient in a repository: git state (branch, head, detached, dirty, ahead/behind), change stats (staged/unstaged/untracked, insertions/deletions), tracked-file count, top-level directories, and file-extension counts. Read-only. For a non-git but readable directory it returns a plain filesystem summary (kind="directory") instead of failing. The extension counts let you infer the project type yourself (e.g. many .kt + build.gradle -> Android/Kotlin) without a curated manifest list.
sentinel_project_snapshot
Read the contents of a file on the target host. The path must fall under one of the agent's configured `file_ops.allowed_read_paths` — directories like /etc/nginx, /var/log, /opt, etc. that the host's operator has chosen to expose. Paths outside that list, or path-traversal attempts via `..`, are rejected with path_not_allowed.
sentinel_read
Read a media or binary file from a host as native MCP content. Use this instead of `sentinel_read` when the file is not text: images, PDFs and audio come back as content the model can actually look at or listen to, rather than as bytes or an unreadable transcription.
sentinel_read_media
Reassemble all chunks into the target file. If `sha256` is provided, the agent verifies the assembled file matches it. Cleans up temp data on success.
sentinel_upload_complete
Remove the label attached to a host. The host_id is unaffected; only the alias is forgotten. Returns {"ok": true, "removed": bool}.
sentinel_remove_host_label
Interact with SentinelX as a product/control plane. ``report`` persists product feedback, feature requests, suggestions, or evidence that SentinelX itself may have malfunctioned. Ordinary host or application failures are not SentinelX bugs unless evidence points to SentinelX; use ``malfunction`` when ownership is unclear. THE REPORT SCHEMA IS CLOSED. A field that is not on this list makes the whole submission fail, so put context in the fields below rather than inventing new ones: host, agent version and timestamps are already recorded from the session and must not be sent. Required in every report: type one of: bug, malfunction, feature_request, suggestion, security, other title one line summary a few sentences Also required when type is ``bug`` or ``malfunction``: expected_behavior what should have happened observed_behavior what happened instead Optional, all free text unless marked: preconditions LIST of strings reproduction_steps LIST of strings (not "steps_to_reproduce") reproducibility one of: always, frequent, intermittent, once, unknown (defaults to unknown) impact who or what it affects evidence LIST, at most 20 items: log lines, ids, timings related_request_ids LIST of strings workaround what you did instead, if anything suspected_cause your hypothesis, labelled as such proposed_solution optional suggestion confidence one of: low, medium, high severity one of: low, medium, high, critical external_issue_provider / external_issue_url Keep observed facts separate from hypotheses, and label confidence in any cause or fix you propose. Do not include secrets: tokens and credentials are redacted, but the safer course is not to send them. The whole report must stay under 48 KB. ``report_status`` retrieves the current lifecycle state of a report by its opaque ``sxrep_*`` identifier.
sentinel_platform
Restart an allowed service through SentinelX.
sentinel_restart
Run a one-off bash or python3 script on the connected host. The script content is written to a temporary workdir, executed, and (by default) cleaned up afterward. Set cleanup=False to keep the workdir for debugging — its path is returned in the response.
sentinel_script_run
Execute a command through SentinelX (must be in the allowed commands list). Set background=true for a long-running command: it returns a job_id immediately instead of blocking, and the result lands in the notifications pool — read it later with notifications(operation="check"). Under background the wall-clock ceiling is raised to 3600s. notify_telegram / notify_resend request a push when the job finishes (on success AND failure). Each accepts: - false (default): no push. - true: use your default integration of that type (errors if you have none, or several with no clear default — name one instead). - "<integration_name>": use that specific saved integration. Any notify_* implies background=true.
sentinel_exec
Recursive content search across a directory subtree. Like ripgrep, but constrained by the file_ops allowlist and returns structured matches. Always skips binary files (heuristic: first 8KB contains NUL) and noise directories.
sentinel_search
Send a text message to a Telegram chat using a saved bot. The target chat is taken from the integration's stored configuration (`metadata.default_chat_id`), set by the authenticated user via the dashboard. This tool deliberately does NOT accept a chat_id parameter — the LLM cannot redirect messages to chats it picks. If you need to reach different chats with the same bot token, create one integration per target chat in the dashboard. Use this for operational notifications: "deploy finished", "backup failed", "container unhealthy", "user requested this summary". It is NOT a chat interface — the bot does not receive replies, and there is no inbound message handling.
telegram_send_message
Send a transactional or operational email via Resend. Use this for emails that need to land prolijo: deploy reports, backup summaries, certificate-expiry notices, weekly digests, invoices. For quick alerts where formality doesn't matter, telegram_send_message is faster to consume. The sending address (`from_address`) defaults to the integration's configured `metadata.default_from`. You can override it if the integration's API key has access to multiple verified domains and a particular send needs a specific one — but the domain MUST be verified in the Resend account this API key belongs to. The recipient list (`to`) is always passed in by the caller because email is, by nature, "send to whoever needs to read this." Unlike Telegram (where the bot has a small fixed set of reachable chats), email targets are open-world. At least one of `html` and `text` must be provided. If both are, Resend sends a multipart email and the client picks. Plain-text fallback is always good practice.
resend_send_email
Designate `host_id` as the default target when host_id is omitted. After calling this, any tool that takes a `host_id` parameter will, if not given one explicitly, route to this host. Useful when you have multiple hosts connected and almost always work with one of them. The host_id must be the EXACT identifier (not a label or hostname). Use sentinel_list_hosts to discover available host_ids. We require the exact id deliberately — labels can be changed or removed, and hostnames can collide between hosts. The default should pin to a specific, stable identity. A default that points to a host which later disconnects is NOT an error at set-time; resolve_session will just fall back to ambiguous_host with a clear "your default is offline" message when the next tool call happens. To switch defaults, just call this again with the new host_id. To remove the default entirely, use sentinel_clear_default_host. Returns: On success: {"ok": True, "host_id": "<id>", "is_connected": bool}. The is_connected flag tells you whether your new default is actually online right now — useful feedback if you pinned a host that's currently offline.
sentinel_set_default_host
Attach a human-friendly label (alias) to one of the user's hosts. The label can then be passed in any tool's `host_id` parameter as a convenient alternative to the long host_id. Labels are also surfaced in `sentinel_list_hosts` output.
sentinel_set_host_label
Get SentinelX internal state.
sentinel_state
Get the help section exposed by SentinelX capabilities. Defaults to the bounded `topic="index"` view. Selectors can drill into `topic` (e.g. "playbooks" or a help section), `path` (one exact leaf), or `playbook` (one playbook), with `offset`/`limit` paging where supported. Pass `topic="all"` for the legacy full response. Requires agent >= 0.10.0; older agents ignore the selectors and return the full response.
sentinel_help
Get SentinelX capabilities, including allowed commands and rich service definitions. Defaults to `detail="summary"` for a bounded discovery view (host/version, ops, limits, policy counts) without command/service values or playbook bodies. Pass `detail="full"` for the legacy full response. Requires agent >= 0.10.0; older agents ignore the selector and return the full response.
sentinel_capabilities
Stage one role file for an edit upload session. Provide exactly one of `content` (utf-8 text) or `content_base64` (binary). `role` must be 'old' or 'new'. Defaults filename to <role>.txt.
sentinel_edit_upload_file
Structured Git operations on a connected host. A single tool with an ``operation`` selector. ``path`` is the repository, or any path inside it, for every operation except ``clone`` (which creates one) and ``ls_remote`` (which needs no local tree). Credentials are never SentinelX's. The network operations run git on the host and use whatever that machine already has: an ssh-agent, a credential helper, a deploy key. Nothing is seen, stored or forwarded here. THERE IS NO ``pull``. ``git pull`` is fetch plus merge, and a merge can conflict, leave a dirty tree, or move HEAD somewhere you did not intend. Fetch, then merge or rebase deliberately. operation="ls_remote" (READ-ONLY, no working tree needed): Read refs from a remote. Use this to learn the SHA a branch is on right now, which is what a forced push needs before it starts. Params: remote (default "origin"), ref_pattern, path (optional; only to resolve a named remote from a local checkout). operation="fetch" (safe: updates remote-tracking refs, never the tree): Params: path, remote, ref. operation="clone" (creates a checkout): Refuses a destination that already exists and is non-empty, so it can never write into someone else's tree. The destination must be under a file_ops entry with access: rw. Params: url, dest, branch, depth. operation="push" (publishes): A forced push MUST pass ``expected_remote_sha``: the commit you believe the remote branch is on. That makes it a compare-and-swap, so if someone pushed since you looked, the push is refused and nothing is lost. A bare unconditional force is not available here on purpose. Params: path, remote, branch, force, expected_remote_sha. operation="diff" (READ-ONLY): One bounded, structured view of the repo's current changes — replaces a chain of ``git status`` / ``git diff --stat`` / ``git diff <file>`` calls. Returns per-file status, insertion/deletion counts, and the unified patch (subject to server caps), plus a summary. Reads resolve under any file_ops path (r or rw). Params: base_ref (default "HEAD"), staged, unstaged, include_untracked, max_files, max_patch_bytes, context_lines. Server-side ceilings always win over the client hints; when they bite, ``truncated.files`` / ``truncated.patch`` are set. operation="apply_patch" (MUTATION, rw): Apply one unified diff (``patch``) touching one or more files, ALL-OR-NOTHING. The repo root must be under a file_ops ``rw`` entry. The agent runs ``git apply --check`` first; on failure nothing is mutated. Pass ``dry_run=True`` to validate only. Use this for a single coordinated multi-file change; single-file deterministic edits stay on ``sentinel_edit``.
sentinel_git
Move a file directly between two hosts you've enrolled, without routing the bytes through this chat. Files up to 512 MiB are supported. The file streams source -> SentinelX hub -> destination one chunk at a time (the hub never holds the whole file, and it never goes peer-to-peer, so neither host needs an inbound port). The destination is verified by sha256 against the source before the transfer is reported complete.
sentinel_transfer_file
Partially update an existing DNS record. Change only the fields you pass; everything else stays as it was. This is a PATCH operation: omitted fields are left untouched. This is the safe semantic — "change proxied to true, leave the rest alone" — that matches how users think about edits. Use cloudflare_dns_list_records first to get the record_id. NOTE on TTL: if you set proxied=True (or the record is already proxied), Cloudflare will force ttl=1 even if you pass another value. To change ttl freely, the record must be non-proxied. To change the record's type or name (e.g. A -> CNAME), delete the record and create a new one — there's no in-place type change.
cloudflare_dns_update_record
Send one chunk of a chunked upload. `index` is 0-based; chunks can be sent out of order — the agent reassembles by index when complete is called.
sentinel_upload_chunk
Upload a file to the connected host's upload base directory. Provide exactly one of: - `content_base64`: file content inlined as base64 - `file_url`: an http(s) URL the agent will fetch `target_path` is relative to the configured upload base on the host (path traversal is rejected). Set overwrite=True to replace existing files.
sentinel_upload_file
Execute a supported service action through SentinelX. Supported actions: start, stop, restart, reload, status, is-active, is-enabled.
sentinel_service
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are SentinelX alternatives on ChatGPT?
As of 2026-09-28, SentinelX competes with Aiven, Cloud Environment Onboarding, ConoHa VPS, Control Plane, DigitalOcean, Gateway, Termalin in ChatGPT Cloud Infrastructure Management, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.