Sync services were built for people saving a document now and then. Agents write many files fast, delete and recreate them, and keep lock files open. That's the worst case for sync.

Fix 1: for code, Git is the sync

If it's code, take the folder out of OneDrive and use Git as the only way the two machines share it. Commit and push from one, pull on the other. Exclude build output and dependencies in .gitignore. It's boring and it works, and the AI is good at writing the commit message.

The catch: you have to remember to push before you leave the desk. When you forget, the laptop has yesterday's code.

Fix 2: one home for the work

The other pattern is to stop copying the work at all. Pick one machine, usually the desktop that's always on, as the home of the project. Everything happens there. Other devices don't hold a copy; they reach in.

You can do that with remote desktop, which is fine for an hour of real work and painful on a phone. Or you can do it from the AI chat you already use, which is what I do.

I build Local Commander, so I'm biased. An agent runs on the desktop; ChatGPT or Claude on any device can read, edit and run things there. From the laptop at a café:

On Home PC, open the Q3 report folder, update the totals in summary.xlsx from the three CSVs that came in today, and tell me what changed.

From the phone, later:

On Home PC, did the build of the site pass? If it did, show me the git log for today.

Nothing moves between devices except the conversation. The files stay on the desktop, the build runs on the desktop, and there's nothing to resolve when you get home.

That is how this site is maintained. The repository lives on my home PC; I write and review from wherever I am, and the AI edits, runs the checks and opens the pull request on that machine. Nothing is synced to the laptop or the phone, because nothing needs to be.

When sync is simpler

Sometimes the boring answer wins. Sync is the better fit when:

• the files are documents and photos that several people open by hand, not a project an agent works on;
• you need them on a plane, in a meeting room without Wi-Fi, or on a phone that only opens attachments;
• the "home" machine is a laptop that travels, so there is no always-on home.

In those cases keep OneDrive or Dropbox, and keep agents out of the synced folder.

What changes in practice

• No conflicted copies. There's one copy.
• No "which machine has the latest version". The home machine does, always.
• Heavy work stays on the strong machine. The laptop doesn't need the 10 GB of dependencies or the GPU.
• The phone becomes useful. You can't edit a spreadsheet on a phone, but you can ask for the edit.

Where it stops

• The home machine has to be on and online. If it's a desktop, turn sleep off; if it's a laptop that travels, this pattern doesn't fit.
• It's not a file-sync service and not a backup. The one copy on the home machine is still one copy; if that disk dies, so does the work. Keep Git for code and a real backup (a second disk, a cloud backup of that folder) for everything else.
• It works through files and commands, not the screen. For layout work in a GUI app, use remote desktop.
• It isn't a sandbox. An approved computer lets the AI do what your user account can do; choose only the folders it needs when you set it up.

Setting it up

1. On the home machine, run npx local-commander-agent@latest (Node.js 20+) and approve it in the browser.
2. Choose access: the whole user account, or only the project folders.
3. Add https://localcmd.app/mcp as a connector in ChatGPT or Claude (and Cursor, if you use it on the laptop) and sign in.
4. Take the project folder out of OneDrive. Keep backups the normal way.

You can cut the machine off from your account at any time.

https://localcmd.app/control-multiple-computers-with-ai

Originally published at localcmd.app.

Most people's first worry about letting an AI near their computers is the same: what if it deletes something. So don't start there. Spend the first week on questions that only need looking.

Here are three. Each one comes with the manual way first, because you should be able to do it without any tool, and then what it looks like when your AI does it for you.

1. Why is my disk full?

By hand. On Windows, open PowerShell and list the biggest top-level folders:

Get-ChildItem C:\ -Force -Directory | ForEach-Object {
  $s = (Get-ChildItem $_.FullName -Recurse -Force -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
  [pscustomobject]@{Folder = $_.Name; GB = [math]::Round($s/1GB, 2)}
} | Sort-Object GB -Descending | Select-Object -First 8

On a Mac or Linux machine, du -xsk ~/* | sort -rn | head does the same for your home folder.

Two things catch people out. First, a full scan of a big disk takes minutes, not seconds; on my Windows machine it took about two and a half. Second, on a Mac the obvious command lies: df -h / shows only the small system volume. Your files live on a separate one, so check df -h /System/Volumes/Data instead. The folder sizes also never add up to the used space, because of system files and folders you don't have rights to read. Expect a gap.

With your AI. Ask: "Why is the disk on my work PC almost full? Show me the ten biggest folders and tell me what each one is. Don't delete anything." You get a ranked list in plain words ("this is an app cache, that is your photo library, that is old installers") instead of a wall of numbers. The deleting, if any, is a separate step that starts only after you say yes.

2. Why is it slow, or why did it restart?

By hand. How long has it been on, what is using the memory, how many programs start with it, and did it restart by itself. On Windows:

$os = Get-CimInstance Win32_OperatingSystem
"Uptime hours: " + [math]::Round(((Get-Date) - $os.LastBootUpTime).TotalHours, 1)
Get-Process | Sort-Object WS -Descending | Select-Object -First 5 Name, @{n='MB'; e={[math]::Round($_.WS/1MB)}}
(Get-CimInstance Win32_StartupCommand | Measure-Object).Count
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1074,6008; StartTime=(Get-Date).AddDays(-7)}

On a Mac, uptime, last reboot | head and ps -Aceo rss,comm -m | head cover the same ground.

A quiet answer is still an answer. If the restart log is empty, nothing restarted it, and your slow day has another cause. One of my machines had been running for 53 days without a reboot, which explained more than any single program did.

With your AI. Ask: "My laptop feels slow. Check how long it has been on, what uses the memory, what starts at login and whether it restarted recently, then tell me the most likely cause." The useful part is the last sentence. You get one conclusion, or an honest "I didn't find a clear cause", and you can ask for the evidence behind it.

3. Did my backup copy everything?

By hand. Compare the original and the copy. On a Mac or Linux machine diff -rq source backup lists files that are missing or differ. On Windows, hash both folders and compare:

$s = (Resolve-Path .\source).Path; $d = (Resolve-Path .\backup).Path
$a = Get-ChildItem $s -Recurse -File | ForEach-Object { [pscustomobject]@{P=$_.FullName.Substring($s.Length); H=(Get-FileHash $_.FullName).Hash} }
$b = Get-ChildItem $d -Recurse -File | ForEach-Object { [pscustomobject]@{P=$_.FullName.Substring($d.Length); H=(Get-FileHash $_.FullName).Hash} }
Compare-Object $a $b -Property P, H

I tried this on a test folder where I had deleted one file and edited another in the copy. Both showed up straight away: one missing, one changed. A comparison by size and date is faster; one by content is slower but catches more. Say which one you want.

With your AI. Ask: "Compare the Photos folder on my desktop with the copy on the external drive. List what is missing or different. Don't copy or fix anything." You get a short list of exceptions instead of a feeling that it probably worked.

Why start here

None of these changes a file. If the AI misreads something, the worst result is a wrong sentence, and you can check it against the commands above. After a week of that, you know how it answers, how it explains itself and how often it says "I'm not sure". That is a better basis for the day you let it change something.

I build Local Commander, so this is the setup I tried it with: a small agent on each computer, and your ChatGPT or Claude chat connects to it. Every example above ran on my own Windows PC and my own Mac. It works through commands and files, not through the screen, so it won't click a dialog for you, and the computer has to be on. You choose what each computer allows, and you can switch any of them off.

If you try the three questions on your own machines, I'd like to hear which one gave a useful answer and which one didn't.

Setup steps and the other first-week questions: https://localcmd.app/use-cases/read-only-first-week

The question changes quickly from “What should I run?” to “Should I let it access my machine?”

I work on Local Commander, so this is a practical question for me. It is also a useful question for anyone choosing between a utility, a script and an agent. The answer depends on what each option can read, change and send elsewhere.

The contrast exists, but it is not universal

In a PowerShell discussion, a user describes finding a command for an Exchange task, pasting it into the terminal and getting a result without understanding what happened.

Under a local AI bridge project, a commenter immediately asks what permissions the AI's file writes run with.

Those are separate people and situations. They do not prove that the same users trust arbitrary scripts but reject AI. There is also a counterexample: a Karakeep user stopped to investigate when an ordinary extension requested access to all websites.

What these examples support is a more useful question: how clearly can someone understand the access needed for a particular task?

Use one small task for the comparison

Consider the first step of a disk-space investigation: report the size and free space of drive C. Do not delete, move or install anything.

Explorer can show this directly. Windows Storage can help with a broader investigation. For that small question, no AI or extra utility is necessary.

A reviewed command is another option:

Get-Volume -DriveLetter C |
  Select-Object DriveLetter, FileSystem, Size, SizeRemaining

The command obtains volume information. It does not establish which folder filled the disk. Understanding this boundary is more useful than deciding that PowerShell itself is safe or dangerous.

We ran that query through hosted Local Commander on a Windows 11 x64 computer on October 20, 2026. At that moment, C had 284,543,627,264 bytes total and 39,215,185,920 bytes free, about 265.00 and 36.52 GiB.

For a folder-level step, we used three synthetic files. A metadata scan returned 2,424,832 logical bytes and correctly identified cache, at 2,097,152 bytes, as the largest subfolder. It did not read those files' contents or change them.

These are results from a small controlled walkthrough. They do not identify the cause of real whole-drive usage or show that AI was faster than a utility. We did not run a comparative benchmark.

Compare the authority, not just the interface

A fixed command and an agent are not identical. An agent can inspect one result and decide to continue. A broad request such as “sort out my disk” leaves more room for unexpected choices than a narrowly reviewed query.

Untrusted text can also influence an agent. Anthropic's safety guidance discusses mistakes and prompt injection. Concern about AI access therefore has a technical basis.

The useful response is to make the task, permissions and evidence visible.

What that means for Local Commander

Local Commander's hosted connector lets a connected AI client perform owner-approved work on a selected computer. In this walkthrough, the conversation selected the target, executed a diagnostic procedure and inspected its actual result.

After owner approval, Full Access uses the user account's rights on that computer by default. The owner can narrow or revoke access. It is not an operating-system sandbox. “Do not delete anything” is an instruction to the assistant; it does not itself create a technical deletion restriction.

Returned command output reaches the connected AI service. In this example, that meant volume information and a synthetic folder report. A task involving documents or logs can expose different data.

For a single free-space number, Explorer is likely the shortest route. The connector is useful when an AI conversation needs evidence from the chosen computer and a clear record of what was checked.

The first demonstration should be easy to inspect: this computer, this command, this output, these limits. A repair or cleanup is another decision.

People do not owe a tool unconditional trust. A better starting point is a task small enough to understand and a result concrete enough to check.

Disclosure: I work on Local Commander. This is a developer's walkthrough, not an independent product review.

Technical reference: Get-Volume.

Originally published at localcmd.app.

Someone on r/mcp put it in one line: "ChatGPT and Claude web can't run local MCP servers." They can't, for a plain reason. Here's why, the two ways around it, and how to choose.

Why the web chat can't see localhost

When you add a connector in ChatGPT or Claude on the web, your browser doesn't talk to the MCP server. The provider's servers do: when the model wants a tool, their backend calls the URL you gave it. From there, localhost means their machine, not yours, and your PC usually sits behind a home router without a public address anyway. The phone apps work the same way.

So the web and phone apps can only use an MCP server at a public HTTPS address. Desktop apps can start a local server as a child process and talk to it over stdio, which is why the same server works in one place and not the other.

That leaves two ways to give your computer a reachable endpoint without forwarding a port on your router.

Option A: a tunnel to your own MCP server

A tunnel tool such as cloudflared or ngrok runs on your computer, opens an outgoing connection to the tunnel provider, and gives you a public HTTPS URL that forwards to a local port. I started this way myself: a small server on my PC, a tunnel, and a login so not just anyone could walk in. It worked.

The steps, at a high level:

1. Serve MCP over HTTP. Many local servers only speak stdio. You need one that speaks Streamable HTTP, or a small bridge that wraps a stdio server in HTTP. Bind it to 127.0.0.1, not to every network interface.
2. Start the tunnel. For example cloudflared tunnel --url http://localhost:8080 or ngrok http 8080. Depending on the tool and setup, the URL may change on each start; a fixed hostname saves re-adding the connector.
3. Put OAuth in front. Either the server implements MCP's OAuth-based authorization, or a proxy in front of it does. This is usually the bulk of the work, and it's the step you can't skip.
4. Add the connector. Paste the public URL, including the MCP path, as a custom connector in ChatGPT or Claude, and sign in.

The risks come with the URL. The moment the tunnel is up, your tools have a public address. Without sign-in, anyone who finds the URL can call them, and a hard-to-guess URL isn't a password: URLs leak through logs, browser history and screenshots. Run the server as a normal user, never as administrator or root, so a bad call can't do more than that account can. Expose only the tools you need. Close the tunnel when you're done, not weeks later.

Option B: let the computer dial out

The other pattern turns the connection around. A small agent on your computer opens an outgoing connection to a hosted MCP service and keeps it open. Your AI app connects to that service over HTTPS, with sign-in. When the model calls a tool, the service passes the request down the open connection to your computer, the agent runs it, and the result comes back the same way. Nothing on your computer listens on the internet, so there is no URL pointing at your machine to leak.

The trade-off is trust: requests and their output pass through the hosted service, so you are trusting whoever runs it.

I build Local Commander, which works this way, so I'm biased. The agent on each computer opens an outgoing WebSocket to localcmd.app and waits for work. Your AI app connects to https://localcmd.app/mcp and signs in with OAuth. From then on, a message typed into Claude on your phone can run on the PC under your desk:

On Home PC, run the tests in my project folder and tell me what failed and why.

The model reads files, runs commands, checks Git or asks a local web service whether it answers, on the computer you named. If more than one computer is online and you didn't say which, the server's instructions tell the model to ask instead of guessing. It works from ChatGPT, Claude, Cursor and other apps that support remote MCP with sign-in.

Setup takes four steps and no code:

1. Install. On each computer, run npx local-commander-agent@latest. You need Node.js 20 or later, on Windows, macOS or Linux.
2. Approve. Confirm the pairing in your browser at localcmd.app.
3. Choose access. Your whole user account, which is the default once you approve, or only the folders you pick.
4. Connect your AI. Add https://localcmd.app/mcp as a remote MCP server in ChatGPT, Claude, Cursor or another app, and sign in with your Local Commander account.

No router settings, no tunnel. If you have more than one computer, the same chat reaches all of them; I wrote about that in How to run one task on all your computers from a single ChatGPT or Claude chat.

Which one to choose

• A tunnel, if you already run your own MCP server, want to own every piece of it, and are ready to build and maintain the sign-in. The tunnel provider still carries the traffic, but the server, the tools and the login are yours.
• A relay, if you want several computers in one chat, don't want anything on your machines reachable from the internet, or don't want to run an OAuth setup yourself.
• Neither, if you only use a desktop app on one computer. A local MCP server over stdio is simpler.

Limits, stated plainly

For the relay route, and for Local Commander in particular:

• The computer has to be on. Awake, online and running the agent. A sleeping laptop can't answer.
• One agent per computer. Each machine you want to reach needs its own install and approval.
• Commands and files, not the screen. It isn't screen sharing, and there's no mouse control. If a job only works by clicking through an app, use remote desktop or a computer-use tool.
• It isn't a sandbox. Once a computer is approved, the AI can do what your user account can do there. Folder rules prevent accidents, like the wrong folder or a stray delete, but they aren't a wall. For stronger isolation, run the agent under a separate user account.
• Output goes to your AI app. Whatever a command returns goes back to the chat, and from there it follows that app's rules.

FAQ

Do I need to open a port on my router for either option? No. Both dial out from your computer. The difference is what ends up public: a tunnel gives your own server a public URL, while a relay gives your computer none. The public endpoint is the hosted service, behind sign-in.

Does this work from the phone app? Yes, wherever the phone app supports the connector you added: it calls tools from the provider's side, like the web app. With Local Commander, the computer still has to be awake, online and running the agent.

If you've hit this wall, I'd like to hear which route you took and where it got in your way. The setup steps are also on the guide page: https://localcmd.app/control-multiple-computers-with-ai. You can block commands and revoke a computer or an AI app at localcmd.app at any time.

Originally published at localcmd.app.

Each of them is a separate trip. Open a remote session, SSH in, walk to the other room, or talk your mom through Settings over the phone. Then do the same thing again on the next machine.

The AI chat you already use knows most of the commands for those jobs. What it lacks is a way onto your computers. This post shows one way to give it that: real prompts, the setup, and where it stops being the right tool.

How it works

I build Local Commander, so this is the setup I know best. It has two parts. A small agent runs on each computer under your user account; it opens an outgoing connection to localcmd.app and waits for work, so there's no port forwarding to set up. Your AI app connects to the hosted MCP server at https://localcmd.app/mcp (Streamable HTTP, OAuth sign-in). When you ask for something, the model calls tools on that server, such as read a file, search, run a command, check Git or ask a local web service whether it answers, and each call runs on the computer it was addressed to. Independent tasks on different computers run side by side; work on the same folder waits its turn. If more than one computer is online and you didn't say which one, the server's instructions tell the model to ask instead of guessing. It works from ChatGPT, Claude, Cursor and other apps that support remote MCP with sign-in.

Three things to ask

Name computers the way they appear in your account. The prompts below are examples; change the names and details to match yours.

1. Which server needs attention?

You have a few machines that are supposed to just run. Instead of logging in to each one:

Check disk space, memory and failed services on all my servers and tell me which one needs attention.

The model sends the same kind of check to each computer, reads what comes back and gives you one answer instead of a row of terminal windows. Then follow up with "Show me the command and output you based that on." Ask for the evidence, not only the verdict.

2. Same project, two machines, different results

The build passes on your desktop and fails on the laptop. Before anyone touches code:

Compare this project on Work PC and Laptop: Git revision, Node and package-manager versions, the lockfile and the build command. Then run the build on both at the same time and show me the first difference that matters, as a table with one column per computer. Don't install anything or edit files.

If the two machines are on different revisions, you see that before anyone starts blaming the environment.

3. Every computer in the family

Disk space is the classic. Include the machines you would otherwise have to visit:

Check free disk space on every computer, including Mom's laptop. On any with less than 10% free, list the biggest folders in the user's profile. Don't delete or move anything.

When one of them turns out to be the real problem, stay in the same chat and narrow it down:

On Mom's laptop, find out why her photo app no longer starts. Check its error logs, whether it is running, and free disk space. Explain it in plain words I can read to her over the phone. Don't uninstall anything, restart the computer or change settings.

The "don't" lines are worth keeping in any prompt that only needs to look. They steer the model, but they are not a lock; that is what access settings are for (more below).

Set it up in four steps

1. Install. On each computer, run npx local-commander-agent@latest. You need Node.js 20 or later.
2. Approve. Confirm the pairing in your browser.
3. Choose access. Your whole user account, which is the default once you approve, or only the folders you pick.
4. Connect your AI. Add https://localcmd.app/mcp as a remote MCP server in ChatGPT, Claude, Cursor or another app, and sign in with your Local Commander account.

There's no code to write. Do the install before you need it: a laptop in another city has to be set up while someone is sitting at it, ideally its owner, and with their permission.

Limits, stated plainly

• It is not a sandbox. Once a computer is approved, the AI can do what your user account can do there, like you at the keyboard. Folder rules prevent accidents such as the wrong folder or a stray delete, but they aren't a wall. For stronger isolation, run the agent under a separate user account.
• The computer has to be reachable. Awake, online and running the agent. A machine that is off or offline can't be reached.
• Dropped connections aren't papered over. If a computer drops in the middle of a task, the work is not re-run on a guess. Each request ends as done, failed or unknown, and an unknown one waits for you to check.
• It works on your computers, not your network. The server's instructions tell the model to decline port scans and probes of other hosts.
• The model can be wrong. It can misread output or pick the wrong fix. Ask for the commands and output behind an answer before you act on it.
• Output goes to your AI app. Whatever a command returns goes back to the AI app, and from there it follows that app's rules.

You can block commands and revoke a computer or an AI app at localcmd.app at any time.

When something else fits

• Tasks that only work through the screen, such as clicking through an app with no command line. Use remote desktop or a computer-use tool.
• Repeatable admin jobs across many servers. Have the AI write the script, then run it with Ansible or over SSH against an inventory you keep. That gives you something you can review and rerun, which a chat doesn't.
• A managed company fleet with patching and compliance. That is what remote monitoring and management (RMM) products are for; this doesn't replace them.
• One computer and one AI app. That app's own computer features may be simpler.
• Web tasks that don't touch files on your machines. A cloud agent needs nothing installed.
• One computer, nothing hosted. The open-source edition (MIT) is a local MCP server for desktop clients such as Claude Desktop, Cursor and Cline, and runs without an account: https://github.com/netbka/local-commander-mcp-agent

FAQ

Can I do this from my phone? Yes, through any AI app on your phone that is connected to Local Commander. The computer must be awake, online and running the agent. If your deploy runs from your work PC, you can start it from a train, as long as that PC is on.

Do I need to write code? No. Install the agent, approve it, and type requests in the AI chat you already use.

Can it run the same task on all my computers at once? Yes. Ask for it in one message. Independent tasks run side by side; work on the same folder waits its turn.

Which systems does the agent support? Windows 11 x64, macOS 14 or later on Apple Silicon, and Linux with a systemd user session (Ubuntu 24.04 x64 or arm64), with Node.js 20 or later.

Does it show me the other computer's screen? It isn't a screen-sharing tool. It works through commands, files and logs, with no mouse control. If a fix needs someone to click through a dialog, use screen sharing.

If your machines are spread across more than one place, I'd like to hear which job you would hand over first, and where this setup gets in your way. The same steps are on the guide page: https://localcmd.app/control-multiple-computers-with-ai

Originally published at localcmd.app.

Two failures you've probably seen

The agent writes a command your shell won't parse. It chains steps with && in Windows PowerShell 5.1, mangles backslashes, or runs a bash-style command that resolves to a different Windows program. A Cursor forum thread calls PowerShell in Cursor "consistently broken", and a Claude Code issue reports that native Windows runs aren't really shell aware: move not found, backslashes broken, find resolving to the Windows binary.

The agent starts a dev server and the chat never comes back. npm run dev doesn't exit, so the tool call waits forever, or the agent decides the server started when it didn't. Kill the terminal and the server often keeps its port; one Cursor user put it as "I have to manually kill it."

Both come from the same place. The agent is handed a terminal and expected to type into it like a person. A person knows which shell they're in and when to stop waiting. A model guesses.

Fix 1: pass a program and its arguments, not a command string

Most quoting bugs disappear when nothing parses a command line. If you write your own agent tools or scripts, start real executables directly:

// Node: no shell in between
import { execFile } from "node:child_process";
execFile("git", ["status", "--short"], { cwd: "C:\\work\\my-app" }, (err, stdout, stderr) => { /* ... */ });

# Python: a list, and no shell=True
subprocess.run(["git", "status", "--short"], cwd=r"C:\work\my-app", check=True)

One Windows catch: npm, npx, pnpm and yarn are usually .cmd shims, and since Node's April 2024 security release, spawning a .cmd or .bat file needs shell: true, so cmd.exe gets involved after all. Keep that safe by refusing arguments that contain cmd metacharacters (& | < > ^ % !) and quoting each argument yourself, or by running node on the tool's JavaScript entry point. If your agent talks to tools over MCP, prefer a command tool that takes command and args as separate fields over one that takes a shell string.

Fix 2: stop PowerShell-only mistakes before they run

A rule in your agent's instructions is a hint; a hook is enforced. In Claude Code, a PreToolUse hook with matcher PowerShell sees each command first, and exit code 2 blocks it and sends your message back to the model:

import json, sys
cmd = json.load(sys.stdin).get("tool_input", {}).get("command", "")
if "<<" in cmd:
    sys.stderr.write("PowerShell has no heredoc. Write the file with the Write tool, or use a @'...'@ here-string.")
    sys.exit(2)

The model reads the message and retries another way. The same pattern catches && on Windows PowerShell 5.1, or helper functions named after built-in aliases such as rd.

Fix 3: treat dev servers as processes, not terminal sessions

Start long-running servers in the background and come back for the log, instead of waiting for them to exit. When one is left behind, the port leads you to it:

netstat -ano | findstr :5173
taskkill /PID <pid> /T /F

The PID is the last column of the LISTENING line. /T stops the process together with everything it started (for Vite that includes esbuild); plain Stop-Process only takes the one PID. And before believing "the server is running", ask it:

curl.exe -s -o NUL -w "%{http_code}" http://localhost:5173/

curl.exe ships with current Windows 10 and 11; a 200 is worth more than a log line that says "ready".

Fix 4: know where your guard rails end

Limiting an agent to certain folders and keeping it away from .env and private keys stops the everyday accidents. People have watched agents read secret files and delete home directories; those are mostly habits, and habits can be blocked.

None of that is a sandbox. If node or python is allowed, a script can do anything your account can do, including deleting files. For a real wall, run the agent's tools in a container, under a separate low-privilege account, or in a VM.

Where these notes come from

I maintain an open-source MCP server, local-commander-mcp-agent (MIT), that packages fixes 1, 3 and part of 4 for agents; it was built around exactly these problems: https://github.com/netbka/local-commander-mcp-agent. If you have a Windows setup that still trips your agent up (unusual paths, non-English usernames, locked-down corporate machines), I'd like to hear about it.

This article was drafted by an AI agent from my project notes and the threads linked above; every command, quote and link was checked before publishing.

Originally published at localcmd.app.