SentinelX
SentinelX

Troubleshooting

Updated October 3, 2026

The problems people actually run into, the exact message you'll see, why it happens and what to do about it. Each section starts with the symptom, so you can search this page for the error you have. If none of them matches, see Still stuck?

"OAuth metadata discovery failed … error decoding response body"

You add SentinelX to Codex (or another MCP client) and it fails before you ever see a login page:

Error: Metadata error: OAuth metadata discovery failed for https://mcp.sentinelx.app/mcp/mcp
  Caused by: HTTP request failed: error decoding response body

Why: security software on your computer is inspecting the client's HTTPS traffic and changing the responses it needs to sign in. The case we've confirmed is Norton 360: its AI Protection → Web monitoring → MCP server scanning option breaks the login. Other antivirus products that inspect HTTPS or MCP traffic can do the same. A plain curl to the same addresses often still works, because these products inspect each application differently.

Fix: exclude your MCP client's executable, or mcp.sentinelx.app and keycloak.pensa.ar, from that inspection. If your antivirus doesn't allow an exclusion, turn the MCP or HTTPS scanning option off. To confirm the cause, switch it off for a minute and try again.

In the case we confirmed, only the sign-in was affected: with the option back on afterwards, regular calls kept working, so turning it off just while you sign in can be enough. You may need to repeat that whenever your client signs in from scratch, for example on a new machine.

A host in Russia reconnects every two or three minutes

The host shows as connected, then drops and comes back, over and over, about every 161 seconds. Commands that run at those moments can fail, and you may see duplicate_session in the agent's log.

Why: since June 2025, many internet providers in Russia throttle connections to services behind Cloudflare, cutting each connection after roughly 16 KB. The agent's connection to SentinelX goes through Cloudflare by default, so it keeps stalling and reconnecting.

Fix: point the agent at our direct endpoint, which doesn't go through Cloudflare. On the host:

sudo sed -i 's#https://mcp.sentinelx.app#https://mcp-direct.sentinelx.app#' /etc/systemd/system/sentinelx-cloud-core.service /etc/sentinelx/identity.json
sudo systemctl daemon-reload
sudo systemctl restart sentinelx-cloud-core

This keeps your host id, enrollment and configuration; run the same commands with the two addresses swapped to go back. Nothing changes in ChatGPT or Claude: your connector keeps using the usual address. An HTTP proxy or a VPN outside Russia also works; the agent honors HTTPS_PROXY set in its service environment.

"-32603 Internal error" for a minute or two, then everything works

Several calls in a row fail with a generic internal error, and shortly after, they work again on their own.

Why: the hub is being updated. For about a minute and a half it stops accepting new calls while the ones already running finish, then it restarts, and agents reconnect by themselves within seconds. ChatGPT shows those refusals as a generic -32603 error.

Fix: wait a minute and retry. If a long command was running at the time, check its result in your notifications before running it again, so it doesn't run twice.

"This tool call was blocked by OpenAI…"

ChatGPT refuses to run a SentinelX operation with a message saying OpenAI blocked it or couldn't determine its safety level.

Why: that decision is made by ChatGPT's own safety layer, before the call leaves ChatGPT. The call never reaches SentinelX, so we have no record of it and can't change the outcome. It tends to happen on operations that change permissions, credentials or the agent's own configuration, and in unattended (scheduled) runs.

Fix: if you believe it's a mistake, use the feedback option on the blocked message so OpenAI sees it. For a change you, the owner, have decided to make, do it yourself outside the assistant: over SSH, or for the agent's policy, with Edit config on the host's card in your dashboard.

Manus asks for a Client ID and Client Secret

Unlike ChatGPT and Claude, which register themselves, Manus's custom MCP settings ask you for OAuth credentials, and an invented Client ID fails at our sign-in page with Client not found.

Fix: register a client once, then copy the two values it returns into Manus:

curl -s https://keycloak.pensa.ar/realms/mcp/clients-registrations/openid-connect \
  -H 'Content-Type: application/json' \
  -d '{"client_name":"Manus","redirect_uris":["https://manus.im/api/webhook/mcp/callback"],"grant_types":["authorization_code","refresh_token"],"response_types":["code"]}'

Use client_id and client_secret from the response, keep https://mcp.sentinelx.app/mcp/mcp as the server URL, and sign in with the SentinelX account where your hosts are enrolled. If Manus asks for the authentication method, it's client_secret_basic.

The host shows offline, but the agent's service is running

Your dashboard and your assistant say the host isn't connected, yet on the machine the service is active.

Why: usually an old agent. Versions before 0.11.12 don't detect a dead connection, so after a network change they can believe they're still connected and never reconnect. Older versions also lack later fixes for searches that ran without a time limit and kept the agent busy.

Fix: restart the agent to bring it back now, then update it from the Managing your agent section of your dashboard. On Linux:

sudo systemctl restart sentinelx-cloud-core

Still stuck?