ChatGPT blocked an RDC call. What should I do?
If ChatGPT says an RDC action was blocked by its safety checks, the safest next step is to stop that specific action and preserve what happened. A successful ping or a different tool call does not explain or clear the refusal.
Do not repeat, disguise, rephrase, or route the same denied action through another tool. Keep the exact refusal and any execution receipt, then continue only with independent diagnostics that are permitted. The message alone does not establish whether the device is offline or what happened upstream.
Start with the safe next steps
What to do next
- Preserve the evidence. Record the exact message, time and timezone, tool name, whether dispatch occurred, and whether RDC recorded a normal execution receipt. Redact device IDs, credentials, account identifiers and private content before sharing.
- Stop that denied action. Do not retry a state-changing operation just to learn whether it ran. If there is no conclusive original receipt, report the result as unknown.
- Check independent causes separately. A ping can confirm reachability for that check; it does not prove every tool call is available or permitted. Distinguish provider refusals from transport, command, process-session and file/schema errors.
- Escalate a continuing block with redacted evidence. Ask the connector or provider for its supported refusal diagnostics, such as tool-catalogue or annotation details and any correlation or reason ID.
What one local test can—and cannot—tell you
One documented session on 17 October 2026, using RDC agent v0.3.0, completed 20 of 20 authorised tasks: 14 dedicated RDC calls and six exact, file-backed Python/ROSE calls. The tasks included configuration and metadata checks, directory listing, file reads, ping, scoped search, a disposable file write/edit/readback and named procedure reads.
This was a single-session convenience sample, not a randomised or controlled trial. Earlier safety-check denials still occurred after upgrading and refining the call pattern. It does not establish a persistent fix or predict future success. A previous estimate of roughly 95% failures was user-reported, not an independently measured baseline.
Separate a safety refusal from a local fault
| What you see | What it may indicate | Safe next step |
|---|---|---|
| Explicit OpenAI safety-check message; no normal result | Invocation refused upstream, or another upstream enforcement layer | Preserve the refusal; stop that action; use only independent permitted diagnostics. |
| Device appears online, but ping or relay fails | Device or transport connectivity | Check the authorised agent, pairing and relay. Online status alone is not end-to-end proof. |
| Python reports SyntaxError, missing module or exit code 1 | Command or application error | Inspect the exact error and verify any authorised correction. |
| A finished process later reports “No session found” | Completed-process record is unavailable | Use a conclusive original receipt; otherwise mark the exit status unknown. |
| A later procedure expects JSON but receives Markdown | Handover or schema mismatch | Use the existing versioned exporter, then verify schema, path, hash and owner. |
Choose a genuine task-specific tool
- Known text or configuration file:
read_file; several known files:read_multiple_files. - Directory contents:
list_directory; timestamps and size:get_file_info. - Scoped search:
start_search, then retrieve results using the actual returned search-session ID. - Authorised small file change:
write_fileoredit_block, followed by an independent readback. - Execution that genuinely needs a process:
start_processwith a reviewed existing executable or script and narrowly scoped literal arguments.
These are distinct capabilities. Do not label a broad process executor as read-only, or use a terminal for a known-file task when a genuine dedicated file tool supports it.
For a genuine Python task, a small reviewed UTF-8 script run by its literal absolute path can avoid nested PowerShell quoting problems. Preserve the original process result and exit marker; “Process finished” alone does not prove exit code zero.
Optional safe diagnostic prompt
Classify this RDC failure using only the tools actually available in this chat. If ChatGPT explicitly refused an action with a safety-check message, stop that action; do not retry, rephrase, encode, or route it through another tool. Keep independent diagnostics separate. Preserve the exact redacted error, timestamp, tool name and original execution receipt; if no conclusive receipt exists, mark the outcome unknown. Distinguish provider refusal, transport, command/schema, missing process-session and application/data errors. Do not change files or settings without authorisation.Related links
- RDC Troubleshooting overview — current scope, evidence limits and practical next steps.
- RDC by Rose project page — project status and intended scope. RDC by Rose is in development; it is not a released service.
- Contact Rose & Etta support with redacted evidence.
Sources and limitations
- OpenAI: Optimize metadata
- OpenAI: MCP tool annotations reference
- OpenAI: Plugin guidelines
- OpenAI Developer Community report (corroborates a symptom, not a shared cause)
- Remote Desktop Commander issue #10
- DesktopCommanderMCP issue #712
- Official RDC releases
Research and writing were prepared with ChatGPT using user-directed diagnostics. The measured result is local and limited; upstream cause and permanent resolution remain unverified.