Intermittent safety blocks with Remote Desktop Commander, including read-only SSH checks
I’m experiencing an issue with ChatGPT and Remote Desktop Commander. Some authorised operations succeed, while others receive this exact message:
This tool call was blocked by OpenAI’s safety checks. Please double check what you are sending.
For the rejected calls, no process ID, SSH output, exit code or detailed explanation is returned. I’m reporting this as a suspected false positive or inconsistent action check, rather than claiming we know the underlying cause.
Environment
I’m using ChatGPT with Remote Desktop Commander connected to my Windows laptop, which accesses my own Ubuntu server over SSH. The server runs my application in Docker Compose.
Commander was updated from 0.2.52 to 0.3.0 during troubleshooting. Its app-specific permission is “Allow all actions.” I understand that this does not override safety protections; I mention it because there is no outstanding approval prompt.
What we have observed
- Local commands and file operations work. SSH connectivity, authorised Docker inspection and remote checksum verification have also succeeded.
- A minimal SSH request running only date -u was rejected. Later SSH checks succeeded. We have not established why, and I am not claiming this proves identical requests behave differently.
- An approximately 295 MB Docker-image archive uploaded successfully, and its SHA-256 matched on the server. A subsequent request combining local release-evidence updates with uploading three smaller release files was rejected.
- A read-only inspection of container network, volume and port metadata was also rejected, despite other Docker inspections succeeding.
The latest release attempt on 14 October 2026, around 19:48 BST, successfully verified the running API and confirmed that the remaining release files were now present on the server with matching checksums. The subsequent request to invoke the release script’s prepare phase received the same safety rejection.
That preparation phase includes checks, backup creation and image loading; it is not entirely read-only. However, the separate diagnostic examples above were read-only. I appreciate that these actions have different risk levels and should not all be treated as equivalent.
We have kept actual software errors separate
A deeper code audit found genuine defects, which were corrected. The candidate then passed 93 container-based tests and 19 tests against disposable PostgreSQL, plus isolated API startup/readiness checks.
Separately, when the release script actually started, it reported:
Declared environment differs from running api
That is an application-generated configuration check—not an OpenAI safety rejection. It remains a separate issue to investigate. We are not assuming that fixing application bugs will clear the tool-action blocks.
What we need help with
Support recommended a narrower request with minimal diagnostic context. We followed that advice, including the single-command SSH check, but it was still rejected at that time.
Is there a known issue affecting legitimate Remote Desktop Commander or custom MCP actions? Is there a supported way to obtain an action-specific reference or explanation so we can distinguish a false positive from a policy decision or connector problem?
I’m not asking to disable safeguards or disguise blocked operations. I’m looking for a practical diagnosis rather than repeatedly restarting the connector, changing permissions or rewriting requests without knowing what failed.
Exact timestamps and redacted tool arguments are available. Credentials, private-key contents and customer data will not be included.