ChatGPT Remote on Windows 0.2.50: non-confirmable safety blocks; request for supported diagnosis and correlation IDs
Summary
Related to #682 and #664, but this report distinguishes a non-confirmable tool-call block from the confirmable “Suspicious Instruction” dialog in #682. It also follows the macOS hard-block report already added to #682. We are not assuming they have the same root cause.
On 16 September 2026, selected Remote Desktop Commander calls from ChatGPT web to the account holder's Windows computer returned one of these exact messages:
Этот вызов инструмента был заблокирован системами безопасности OpenAI. Внимательно проверьте отправляемые данные.
Этот вызов инструмента был заблокирован OpenAI, поскольку мы не смогли определить статус безопасности запроса.
Translations: “This tool call was blocked by OpenAI's safety systems. Please carefully review the data being sent.” / “This tool call was blocked by OpenAI because we could not determine the safety status of the request.”
No process ID, exit code, tool request ID, or relay operation ID accompanied these responses. We cannot establish whether they reached the relay/device. Absence of output is not being treated as proof of no execution.
Verified environment and controls
- Hosted Remote Desktop Commander connector in ChatGPT web.
- Remote
get_configcurrently reports Desktop Commander 0.2.50, Windows x64, Node 24.15.0, PowerShell default shell. - The user reports app-specific Allow all actions is enabled. This is not treated as overriding client safety decisions.
- In the same ongoing workflow, independent
read_file,read_multiple_files,list_directory,get_config, and somestart_processcalls succeed. - Selected blocked operations included reading a particular local assistant conversation, a compound read-only diagnostic/help invocation, and starting a local coding task. Some other earlier blocked work involved credentials; those cases are not conflated with credential-free diagnostics.
- A separate local Codex JSON-RPC
-32600error was also found:readOnlywas supplied wheresandboxexpectsread-only. Correcting that documented parameter let the separate read-only diagnostic handoff be accepted. This is a technical API validation issue, not evidence that a safety block was bypassed or fixed. - The original blocked operations have not been replayed as part of this report. No safety controls or permission checks have been disabled.
Relationship to existing discussion
In #682, @wonderwhy-er said the description issue was not yet fixed, and @JavierGarcia131012 reported work on capability-focused/compact descriptions. The current discovered start_process and interact_with_process descriptions still contain policy-prescriptive wording. That is observable metadata, but not proof it caused these non-confirmable blocks.
GitHub's latest release endpoint currently reports v0.2.50. Its release notes do not identify a #682 fix. A later hosted-service deployment could be separate from the local package version.
Questions for maintainers
- Does #682 cover these hard blocks, or should they remain a separate compatibility/observability issue?
- Is there a released or hosted-side fix for the tool-description problem? Please identify the exact package version, PR/commit, or hosted deployment and the supported refresh procedure.
- Which layer supplies the descriptions ChatGPT sees: hosted connector, installed device package, or both? Is a schema/description revision or digest exposed?
- What supported, sanitized audit evidence can distinguish not dispatched / relay received / device received / process started / completed? Can an operation/correlation ID be made available without recording prompts or credentials?
- For a suspected false positive, should we escalate to Desktop Commander or OpenAI Support, and what minimal evidence do you need when no request ID is exposed?
We are requesting a supported fix, false-positive diagnosis, and reliable execution receipts—not a way to evade safeguards. No private paths, device identifiers, conversation IDs, credentials, or raw logs are included.
Report reference: DC-WIN-HARD-BLOCK-20260916.
Source: wonderwhy-er/DesktopCommanderMCP