With remotify-mcp, an AI assistant can send shell commands to another computer and receive their output. This can help with inspecting logs, checking services, or gathering information for troubleshooting while you continue using the AI application on your own computer. Commands and results pass through an HTTP relay, without an SSH connection.

In supervised mode, the person at the receiving computer can review each incoming command and decide whether to run it. The documentation also describes an automatic mode that executes commands without asking the operator for confirmation. [4]

Disclosure: I work on improving remotify-mcp's visibility and have a professional connection to the project. This article explains how it works, then walks through my setup on October 30–31, 2026, and the test across two computers on October 31. I also used AI assistance during the technical setup.

How the components connect

remotify-mcp is an MCP server that runs locally. MCP, short for Model Context Protocol, connects AI applications with external tools; an MCP server can run on your own computer. In this case, that server makes remote command execution available to the assistant. [2]

Three components work together. The AI application and remotify-mcp run on one computer, while a receiving program waits for requests on the other. The project calls that program a listener, and the relay connects the two sides. [1]

The AI application communicates with the local MCP server over stdio, or standard input and output. Commands and results travel through the relay over HTTP(S), so the client configuration needs the command that starts the local MCP program. [1]

Preparing my laptop

I first installed Claude Desktop on my Windows laptop and signed in with a Free account. I used the Chat interface and pinned remotify-mcp to version 0.6.2 for the test. I chose supervised mode to try approving one command and rejecting another on the receiving computer.

The first obstacle appeared on my own laptop. Neither node --version nor npx --version returned a version number in Windows Command Prompt, so I installed Node.js. In a newly opened Command Prompt, the versions then appeared as Node.js 26.13.0 and npx 11.20.0.

To check them, I pressed Windows + R, typed cmd, pressed Enter, and ran:

node --version
npx --version

In my Claude installation, Settings → Developer → Edit config opened claude_desktop_config.json. I added the remotify startup configuration, using the pinned 0.6.2 package version. I kept the settings already present in the file.

On the first launch, remotify showed “Server disconnected.” The log contained an npm certificate verification error:

UNABLE_TO_VERIFY_LEAF_SIGNATURE
unable to verify the first certificate

Using Node.js's system certificate store resolved the issue in my environment. I first checked whether the package was accessible with that setting in Windows Command Prompt:

set "NODE_USE_SYSTEM_CA=1"
npm view remotify-mcp@0.6.2 version

The response was 0.6.2. I then added NODE_USE_SYSTEM_CA to the remotify entry in Claude's configuration, because the set command only applied to that Command Prompt session. My Node.js version supports this setting, which includes the system's trusted certificates in certificate verification. [3]

Here is a standalone, minimal example of the configuration that worked for me:

{
  "mcpServers": {
    "remotify": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "remotify-mcp@0.6.2"
      ],
      "env": {
        "NODE_USE_SYSTEM_CA": "1"
      }
    }
  }
}

For an existing configuration, add the remotify entry to its mcpServers object while preserving other servers and settings. The certificate-store setting addressed the specific error I encountered; check that your Node.js version supports NODE_USE_SYSTEM_CA.

After saving the file, I fully quit Claude, including the application still running in the system tray, and restarted it. The local MCP server then showed Running, and Claude successfully retrieved the remotify session details.

The test across two computers

On the receiving Windows computer, we opened a Bash terminal and checked the tools with bash --version and curl --version. The first paste inserted unwanted control characters before the command, causing Bash to report an error. Both checks worked when we typed the commands manually.

We then created a separate test folder and switched into it:

mkdir -p ~/remotify-teszt
cd ~/remotify-teszt

On my laptop, I asked Claude for a fresh remotify session. The remote_session_info tool returned the command needed to start the listener, and we chose the supervised version.

The following example shows the command's structure. YOUR_SESSION_KEY is a placeholder for your own session key; copy the actual command from the tool's response:

curl -fsSL 'https://relay.remotify.run/r/YOUR_SESSION_KEY' | bash

This command downloads the listener program from the relay and runs it with Bash. The receiving computer's terminal displayed:

remotify: connected [supervised] - preview each command before it runs. Ctrl+C to stop.

We left that terminal window open. I then asked Claude on my laptop to use the remote_exec tool to send exactly pwd and show the actual output.

I encountered two separate approval steps. On my laptop, Claude requested permission to use the MCP tool, which I granted by clicking Allow once. On the other computer, the listener then asked for permission to execute the command with Run? [y/N].

We answered y there. The command ran, and Claude returned the path of the folder we had created on the other computer:

/c/Users/[username]/remotify-teszt

I have anonymized the username in that output. The returned path matched the one we had previously checked in the receiving computer's terminal.

The second request was date, which would have displayed the current date and time. This time, we answered n on the receiving computer. Claude displayed the tool's actual response:

[declined by operator]

No date output was returned for the rejected request. The two tests covered the full path of both an approved command and an operator rejection, from my Claude conversation to the other computer and back.

What I learned, and the limits of the test

Understanding the role of each component helped me most during setup. Running showed that the local MCP server had started; completing the remote workflow also required starting the listener on the other computer. The process came together when the local tool call produced an approval prompt on the receiving computer, followed by a result in my conversation.

We already had access to the receiving computer at the start of the test and opened its terminal ourselves. In this case, “without SSH” described how commands and responses were transported. A supervised session needs an operator present, and the listener can be stopped with Ctrl + C. [4]

The relay is also part of the trust model. According to the documentation, it stores commands, output, and history for the session, so the relay operator may have access to the data passing through it. Self-hosting the relay is also an option. Treat the session key as an access credential: approved commands run with the permissions of the user who started the listener. The test folder alone does not restrict those permissions. [4]

This was a functional test involving two simple commands, one Windows-to-Windows setup, and supervised mode. Both approval and rejection worked in that setup, and the experience showed which preparation steps and permission prompts a first-time user needs to understand.

If you have used a similar tool, I would be interested to hear when approval by the person at the receiving computer is useful in your workflow. Technical corrections to this article and experiences from your own tests are welcome too.

Test date: October 31, 2026. My laptop: Windows, Claude Desktop Free, Node.js 26.13.0, npx 11.20.0, remotify-mcp 0.6.2. Receiving computer: Windows, Bash 5.3.15(2), curl 8.23.0. The session key shown is a placeholder, and the username in the folder path has been anonymized.

Sources

1. remotify-mcp — MCP README
2. Model Context Protocol — Architecture overview
3. Node.js — NODE_USE_SYSTEM_CA
4. HTTP command relay — operation and security model