DEV Community: ReconDeck

How to let ChatGPT work with files on your own Windows PC over MCP

ReconDeck — Wed, 28 Oct 2026 02:46:11 +0000

Disclosure: I make Bridgerator, the tool used in this walkthrough. I'll try to be specific about what it does and, just as important, what it doesn't protect you from.

ChatGPT is good at reading, summarizing and rewriting text. But your files are on your PC, and ChatGPT lives in a browser tab. The usual workaround is to copy and paste, or to upload files one at a time. That gets old fast if you want help with a whole folder of notes, invoices, logs or a project directory.

The Model Context Protocol (MCP) fixes this. An MCP server exposes "tools" (read a file, search a folder, run a command) to an AI app, and the app calls them when it needs to. ChatGPT supports custom MCP servers, and so do Claude, Codex, Cursor, VS Code and others. The open question is how to expose your own Windows PC to them without opening your network.

This post walks through one way to do it, then goes through the safety model, because that is the part that matters.

What you end up with

After setup you can ask ChatGPT things like:

"Find all PDFs in my Documents\Invoices folder that mention 'March' and list them."
"Rename the files in this folder to YYYY-MM-DD - title based on their contents."
"Read these three config files and tell me what differs."
"Create a summary.md from the notes in this folder."

Bridgerator can read, search, create and edit files, organize folders, run PowerShell or cmd commands, manage processes, take screenshots with text recognition, and check the PC's health. It works on Windows 10 and 11.

How the connection works

A common worry with local MCP is "do I have to open a port on my router?" Here you don't. A small bridge program runs on your PC and makes an outbound secure WebSocket connection to a hosted MCP endpoint. ChatGPT talks to that endpoint; the endpoint forwards tool calls down the connection you already opened. No inbound ports, no public IP, no port forwarding, and no admin rights.

Two things worth being precise about:

Traffic uses TLS, but the server has to decrypt requests in order to forward them. So this is not end-to-end encrypted. The security page states that file contents, paths, search results, command text and output pass through server memory and are not stored.
Each PC gets its own device key when you confirm it in the browser. The key stays in your Windows profile and the server keeps only a one-way hash.

Setup walkthrough (ChatGPT)

Create an account at bridgerator.recondeck.com (Google or e-mail).
Install the bridge on your PC. Use the download on the website, or, if you have Node.js, run npm i -g bridgerator. No admin rights needed.
Confirm the computer. A browser tab opens asking you to approve this PC. That is when the device key is issued.
Add the server in ChatGPT. Go to chatgpt.com/plugins and add a custom MCP server with the URL https://mcp.bridgerator.recondeck.com/mcp, using OAuth sign-in. ChatGPT gets access only after OAuth 2.1 sign-in with PKCE, and it sees only your devices.
Try something harmless first. For example: "List the files in my Downloads folder."

Other MCP apps (Claude, Codex, Cursor, VS Code) use the same server URL. Apps without OAuth support can use a personal access key. That key gives full access to your PCs, so keep it like a password.

The safety model

Giving an AI access to your files is only reasonable if you can limit it. Here is what is available, with the caveats the documentation itself lists.

Allowed folders

By default there is no folder list, which means ChatGPT may work in any folder except Bridgerator's own folders. That is permissive, and I'd change it right away. If you set a folder list, ChatGPT can only work in those folders. A few details:

Network and UNC paths are always refused.
Paths are resolved through symlinks and junctions before checking.
Excluded paths are removed from search results and listings.
An optional "Protect sensitive folders" setting (off by default) also excludes things like AppData, Startup, PowerShell profiles, and key and config folders.
readOnlyDirectories blocks writes in the folders you choose.
The OneDrive root is open by default, and searching it can download online-only files. Worth knowing before you point ChatGPT at it.

My suggestion: start with one project folder, not your whole profile.

Confirmations

You can require approval on the PC itself for risky actions. Requests show up as native Windows notifications. If you don't answer within 2 minutes, or you close the prompt, the answer is Deny.

By default, delete and dangerous_commands are on. write_files, move, any_command, install and scheduled_scripts are off by default and can be turned on. Confirmations are configured from the command line. The assistant cannot edit confirm.ini; it can only request that confirmations be turned off, and lowering protection requires your approval on the PC.

Undo and the Recycle Bin

Simple delete commands go to the Recycle Bin by default (scripts and other programs are not caught by this).
Undo snapshots are on by default: a copy of files is kept before ChatGPT changes them, for 7 days or up to 500 MB, and files over 50 MB get no copy. "Undo AI changes" restores them.
Pausing on mass deletes or moves exists, but it is off by default (limit is 20 per minute).

What it does not protect you from

I'd rather you read this here than find it out later:

The terminal is not a folder sandbox. Commands run with your Windows user's rights. The bridge refuses commands that name excluded folders, but that is a courtesy, not a boundary. blockedCommands is a safety net that can be bypassed.
Code already running on your PC could click the confirmation buttons, and command patterns can be evaded.
"Allow 10 min" in a confirmation skips checks for 10 minutes.
The default access preset is Full. Tighten it.
Results go to ChatGPT, where OpenAI's policies apply. Don't expose anything you wouldn't be comfortable sending there.
Packages are published from the author's PC without npm provenance. If that matters to you, the security page publishes SHA-256 hashes and describes how to compare the package against the git tag (an empty git diff against v1.1.15 means they match).

The bridge runs as your own user, never as SYSTEM, and the executables are signed. The practical conclusion: treat the AI like a fast, well-meaning colleague who has your login. Scope the folders, turn on confirmations for anything destructive, and keep the undo window on.

What's stored on the server

Account email, password hash, device list, a monthly call counter, and an optional activity log of tool names and times kept for 30 days. Not stored: file contents, paths, search results, command text or output. The bridge also sends install/update events and a daily heartbeat with a random install ID, versions, OS language and per-tool counts. It never sends paths, file names, command text or output, and telemetry can be turned off.

Pricing

Free is 10,000 tool calls per month on any number of PCs. Pro is $10 per month with unlimited calls. The counter is per account, resets on the 1st at 00:00 UTC, and chat messages are not counted. For occasional file chores the free tier goes a long way.

A sensible first session

Set a folder list with one test folder.
Turn on confirmations for write_files as well, at least for the first week.
Ask ChatGPT to organize or rename a few copies of files.
Check the result, then try "Undo AI changes".

If the undo works as you expect, widen the scope gradually.

If you try it and something in the safety model is unclear or wrong, I'd like to hear about it: the contact is info@recondeck.com. And if you have a different approach to exposing a Windows PC to MCP apps, tell me in the comments. I'm curious what other people consider the right default.

How we try to stop an AI operator in an RMM from running format C: (5 layers, and where they stop)

ReconDeck — Wed, 28 Oct 2026 02:44:42 +0000

Disclosure: I work on ReconDeck, a self-hosted RMM with a built-in AI operator. This post describes how its safety design works, based on what we publish on recondeck.com. It is vendor material, so read it with that in mind.

Letting an LLM run PowerShell as SYSTEM on client machines is the thing most MSP owners fear about AI in RMM. It is a reasonable fear. A model that is wrong 1 time in 200 is still a problem when it can run Remove-Item -Recurse on a customer's file server.

This post walks through how we approach it: five layers, each assuming the previous one failed. I'll also say what we don't claim, because "AI safety" posts that skip that part aren't worth much.

The threat model

The operator is an AI agent that works inside the RMM console. It diagnoses incidents on Windows and Linux machines and proposes fixes. We assume:

The model will sometimes be confidently wrong.
Prompt text (ticket bodies, log lines, file names) can contain instructions nobody intended.
A single check, whether a prompt rule or a regex, will eventually be bypassed or misconfigured.

So no single layer is trusted. The design goal is that a destructive command needs to get past several independent mechanisms, and that a human is on the hook for the ones that matter.

Layer 1: a hard block, on the server

The first layer is not an AI at all. Destructive commands are blocked server-side, before they are dispatched to the agent. Our published examples are format, del and Remove-Item -Recurse. Running one of those requires explicit operator confirmation.

Two design points matter here:

It is deterministic. A model can be talked into things. A pattern check on the server can't be argued with, whatever the prompt says.
It runs on the server, not in the agent or the prompt. If the safeguard lived in the system prompt, a prompt injection could try to override it. If it lived on the endpoint, a compromised endpoint could skip it. Server-side means the check sits on the path every command has to take.

A sketch of the idea (illustrative pseudocode, not our source):

HARD_BLOCK = [r"\bformat\b", r"\bdel\b", r"Remove-Item\s+.*-Recurse"]

def dispatch(cmd, session):
    if any(re.search(p, cmd, re.I) for p in HARD_BLOCK):
        if not session.operator_confirmed(cmd):
            return Blocked("destructive: needs explicit operator confirmation")
    ...

The obvious weakness is the one every blocklist has: it only catches what it recognizes. That is why it is layer 1 and not the whole answer.

Layer 2: an AI reviewer for risky commands

Before a dangerous command runs, a second, "senior" model assesses the risk. It can block the command or propose an alternative.

The demo on our site shows this. The operator proposes format C: on a machine named 017-001. The reviewer stops it, explains that it would wipe the OS with no recovery, and suggests alternatives: sdelete with confirmation, or an MDM reset with rollback.

Why have a model review a model? A blocklist can't judge intent. A reviewer can see that a command that looks harmless is aimed at the wrong target, or that a cleanup script would touch more than the ticket needs. The reviewer is also a different call with a different job, so it doesn't share the first model's momentum toward "just do what was asked."

The cost is that this layer is probabilistic. It reduces risk and doesn't remove it, which is why it comes after the deterministic layer and not instead of it.

Layer 3: permission modes with auto-expiry

The operator doesn't hold standing power. It works in named permission modes, each with its own permissions and an auto-expiry timer. The modes we list are:

Read-only
Single agent
Bulk operations
Destructive

The idea is least privilege over time. Diagnosing a slow PC needs read-only. Fixing one machine needs single-agent. Touching a whole fleet needs bulk operations, which is a separate permission from the rest. The riskiest mode is not a permanent setting: it expires on a timer, so the system falls back to a safe state if someone forgets to switch it off.

This also limits the damage of a mistake. A bad command in read-only mode can't change anything. A bad command in single-agent mode can only hit one machine.

Layer 4: an audit log of everything

Every AI and operator action is recorded: who acted, what was done, when, on which agent, and the result. The log is visible in the console.

An audit log doesn't prevent anything. It does three other jobs:

You can reconstruct what happened after an incident.
You can tell "the AI did it" from "a technician did it" and see who approved what.
You get evidence for reviewing and tuning the other layers: which commands the reviewer blocked, which were confirmed anyway.

Layer 5: your own infrastructure

The server runs in the customer's data center. This layer is about control and data flow more than command safety, but it matters for the same reason: the system that enforces layers 1 to 4 sits on infrastructure you operate, not on a vendor's multi-tenant cloud.

Two related facts:

The AI runs on your own AI subscription, via what we call the AI Bridge. There are no extra per-request charges from us. This is a pricing contrast with RMMs that sell metered AI credits. It also means your prompts and context go to whichever model provider you connect, which is a data-flow decision you make.
The agent is a Rust binary, about 30 MB of RAM, for Windows 7 and later (x86/x64) and Linux (Ubuntu and other distributions). It has auto-update with beta/prod channels, staged rollout and built-in kill switches. Clients can also end a remote session themselves from the tray with an "End session" button.

How the layers fit together

Take the demo case, an AI that decides to reformat a drive:

The command matches the hard block. It can't run without explicit operator confirmation.
If it gets as far as review, the senior model assesses it and can block or redirect.
Whatever mode is active limits what the session may do at all, and the riskiest modes expire.
Whatever happens ends up in the audit log.
All of it runs on a server you host.

The human stays in the loop where it counts. The AI diagnoses and proposes, and the technician approves. This matches where the market is: other vendors also keep a human approval step (NinjaOne has said fully autonomous AI won't arrive in 2026). We don't think "fully autonomous" is the right pitch today, and we don't sell it.

What we don't claim

This is the section I'd want to read as an MSP owner.

No guarantee of safety. Layers reduce risk. They are not a proof. A command nobody anticipated, in a form the hard block doesn't match, could reach the reviewer, and the reviewer is a model.
A blocklist is a blocklist. Obfuscated commands, indirect execution (scripts that call destructive operations internally) and tools we haven't listed are the classic ways around pattern matching. The reviewer and permission modes exist because of this, and they don't close the gap fully.
The human can be the weak point. "Explicit operator confirmation" only works if the operator reads what they confirm. Confirmation fatigue is real.
Details we haven't published. The site doesn't state timer durations, the reviewer model's identity, the full definition of "destructive", how modes get assigned, audit-log retention, or whether a reviewer's block can be overridden. I won't guess at them here. If those matter to you, ask us before you rely on them.
The numbers are vendor claims. Anything quantitative on our site, including the incident-resolution and productivity figures, is stated by us and is not independently verified. This post doesn't rely on them.
No third-party audit or red-team report yet. We think one is the right next step for a design like this. It doesn't exist as a public document today.
BYO model shifts responsibility. Using your own AI subscription means data goes to your chosen provider. That's your call, and your compliance question.

Takeaways if you're building something similar

Put the first safeguard outside the model. A deterministic server-side check can't be prompt-injected.
Don't give standing privileges. Modes with expiry timers turn "the AI is allowed to do X" into a temporary state.
Use a second model as a reviewer, not as the only guard. It catches what patterns can't, and it is itself fallible.
Log everything with actor, target, time and result. You'll need it the first time something goes wrong.
Keep a human approval step for destructive work, and design the UI so confirming isn't a reflex.
Say publicly where it can fail. It's the only way a skeptical buyer can judge the design.

Questions for you

If you run an MSP or manage a fleet: what would you need to see before letting an AI touch production endpoints? A public red-team report? A dry-run mode? Per-command approval for every write? I'd like to hear what's missing from this design.

More on the design: recondeck.com/en/. Contact: info@recondeck.com.

ReconDeck is developed by KLIK.BEL, Minsk. I'm affiliated with the vendor.