[feat][Remote MCP] Native artifact upload from ChatGPT to a remote device without Base64-in-MCP
Summary
Remote Desktop Commander can read/write local files once bytes are on the device, but the hosted ChatGPT integration currently has no native path for transferring an artifact generated or attached in ChatGPT into the remote device filesystem.
A Base64-in-JSON workaround is possible and was verified bit-identical, but it expands payloads by about 33%, consumes MCP/JSON transport capacity, and is a poor fit for ZIP/WAV/PDF and other larger binary artifacts.
I prepared a device-side reference implementation against Desktop Commander 0.2.51 that keeps artifact bytes out of ordinary MCP tool arguments.
Proposed architecture
- ChatGPT-hosted action receives a real host-native file/file reference.
- Hosted Remote MCP ingests it into private temporary storage and computes authoritative size + SHA-256.
- Hosted relay dispatches metadata-only
__dc_artifact_receive_v1to the selected device. - Compatible devices advertise
capabilities.artifact_receive_v1=true. - Device pulls bytes from a fixed authenticated hosted endpoint, verifies size/hash, and commits to an allowlisted local destination.
- The internal receive command is not exposed through
tools/list.
Reference implementation
Base: 092ce0b841e86455f12e41f4dc36399a7522ecb5 (0.2.51)
Reference successor tree: b984069ab5b2108744b63945ad41ae66e3fa405b
Two local reference commits:
feat(remote): add internal artifact receiver reference implementationfeat(remote): advertise artifact receiver capability
The implementation adds an authenticated fixed-origin transfer client, size/SHA-256 verification, deny-by-default upload roots, symlink/junction escape checks, no-clobber commit behavior, idempotent retry handling, stale-part cleanup and byte/token redaction.
Local evidence
npm run test:artifact-handoff passes T01–T28 (28/28) plus H01 capability negotiation.
The compiled local MCP catalog remains 26 ordinary tools, and __dc_artifact_receive_v1 is absent from tools/list.
A deterministic 00..FF 256-byte fixture verifies SHA-256 40aff2e9d2d8922e47afd4648e6967497158785fbd1da870e7110266bf944880.
The full upstream runner was also executed; five of six observed failures were reproduced on the clean upstream base during A/B testing, while the artifact-specific suite remained green.
Hosted work required
The public repository contains the Remote Device/client side, but the host-native file ingress and private transfer store are hosted-service responsibilities.
The hosted action needs to create/bind a transfer, expose GET /artifact-transfers/{id}/content to the authenticated bound device, and map the final device receipt back to the action result.
Acceptance for hosted rollout is H01 plus T29–T32:
- actual host-native file input with no artifact Base64 in model arguments;
- supported catalog refresh exposes the new action;
- internal receive command remains hidden;
- existing Remote Desktop Commander tool schemas/behavior remain unchanged.
Current hosted-boundary verification (2026-09-17)
The current ChatGPT-facing Remote Desktop Commander catalog still exposes 30 tools and no upload_artifact / host-file parameter. A real 256-byte ChatGPT-side test artifact exists, but there is currently no hosted action to which its file handle/stream can be delivered without falling back to Base64. Therefore T29/T30 are externally blocked today rather than simulated.
Related, not duplicate
- #681 documents the hosted/local schema-catalog boundary.
- #714 requests configurable self-hosted Remote MCP backend selection.
This issue is specifically about native artifact ingress and device transfer semantics.
Request
Would the maintainer/provider be open to this two-plane design and the public-repo receiver patch?
The handoff pack includes git-format patches, provider contract, security invariants, tests and rollout criteria; no production service or existing installation was modified while preparing it. I can provide the patch inline in this issue for direct git am/git apply reproduction.
Source: wonderwhy-er/DesktopCommanderMCP