DEV Community: Peter Mamrukov

Start a long job on your PC and check it from your phone

Peter Mamrukov — Wed, 28 Oct 2026 16:02:56 +0000

Some jobs take an hour: the full test suite, a video export, copying a photo archive to a new disk, re-indexing a database. You start it, and then you want to leave. The question in every thread about this is the same: how do I see how it's going without walking back to that screen?

There are three good answers, and they suit different jobs.

1. tmux plus SSH: the terminal, from anywhere

Start the job inside tmux (or screen) on the machine. Reach the machine over Tailscale or your VPN, SSH in from your phone with an app like Termius or Blink, and run tmux attach. You see exactly what you'd see at the desk.

Good for: anything you started by hand in a terminal, and anyone comfortable with a terminal on a phone keyboard.
Watch out for: the job dies if you started it outside tmux and the terminal closes. And a 6-inch screen full of compiler output isn't a summary.

2. Claude Code's Remote Control: the same coding session, on another device

If the long job is a Claude Code session, Claude Code has this built in. Run claude remote-control on the machine (or type /remote-control inside a session) and pick the session up from claude.ai/code or the Claude app. The work keeps running on your computer; the phone is a second window onto the same conversation. It needs a paid Claude plan and a claude.ai login.

Good for: an interactive coding session you want to steer from the couch.
Watch out for: it's one session on one machine. It doesn't help with a backup script or a job on a second computer.

3. Ask your AI chat to start it, then ask again later

The third pattern starts the job from the chat itself. You ask ChatGPT or Claude to run the job on a named computer; the job keeps running on that computer after the chat answers; later you come back to the same conversation and ask how it's going. Your chats sync between desktop and phone, so "later" can be from the train.

I build Local Commander, which works this way, so I'm biased. A real exchange looks like this:

On Home PC, copy D:\Photos to the new disk E:\Photos with robocopy, keeping timestamps. Log to E:\copy.log. Tell me when it's started; don't delete anything on D.

The command starts and the chat answers within seconds with "started". An hour later, from the phone, in the same chat:

How's the copy going? Show me the last lines of the log and whether it finished with errors.

The AI asks the computer for the job's status and output and gives you a one-paragraph answer instead of a wall of log. If something is wrong: "Stop the copy." It sends the cancel to that computer.

What makes "ask again later" work is that the job has an identity. When the chat starts it, the computer hands back an operation ID, and the job is written to a small journal on that computer. Later questions ("how's it going", "show me the log", "stop it") refer to that ID, so the answer is about the job you started, not a fresh guess. If the connection between the chat and the computer drops for a moment, the job keeps running where it is; the result waits in the journal until the chat asks for it.

The real one I checked from the phone this week was not a photo copy. I ship the Local Commander website itself this way: from the chat I start the release script on the server, it rebuilds the site image and runs its checks for a minute or two, and I ask for the result from wherever I am.

Good for: jobs that aren't a coding session — copies, backups, test runs, exports — and machines other than the one in front of you.
Watch out for: it reports output and status, not the screen. And as with the other two, the computer has to stay awake.

Which one when

Job	Best fit
Something you started by hand in a terminal	tmux + SSH
A Claude Code session you want to keep steering	Remote Control
A copy, backup, export or test run you'd rather describe than type	Ask the chat to start it
Several jobs on several computers	Ask the chat; name each computer

The part everyone forgets: sleep, offline, restart

Whatever you pick, a laptop that sleeps when you leave stops the job. On Windows, set "When plugged in, put my device to sleep after" to Never for the duration, or run powercfg /change standby-timeout-ac 0 and set it back later. On macOS, caffeinate -i in front of the command keeps the Mac awake until it finishes. On Linux, systemd-inhibit does the same.

Three different things can happen while you are away, and it helps to know which one you got:

Offline for a while (Wi-Fi hiccup, the relay restarts): the job keeps running on the computer. When the connection is back, "how's it going" gets the real status from the journal.
Asleep: the job is paused with the computer. It resumes when the computer wakes, but a copy with a timeout or a test with a clock may have failed by then. The status tells you.
Restarted (power cut, Windows Update): the job is gone. Nothing here restarts it for you, and it is not re-run on a guess; the chat reports the outcome as unknown, and you decide whether to start it again. Check the log before you do, so a half-finished copy is not copied twice.

Setting up the chat way

On the computer, run npx local-commander-agent@latest (Node.js 20+) and approve it in the browser.
Choose its access: the whole user account, or only the folders the job needs.
Add https://localcmd.app/mcp as a connector in ChatGPT or Claude and sign in.

It isn't a sandbox: an approved computer lets the AI do what your account can do, so for a long unattended job, give it only the folders it needs. You can cancel the job or cut the computer off at any time.

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

Originally published at localcmd.app.

My PC started lagging once AI agents moved in. Two causes, both fixable by hand

Peter Mamrukov — Mon, 26 Oct 2026 19:42:48 +0000

At some point my home PC started to lag. Not crash, just hesitate: a window takes a second to open, the cursor freezes for a beat. That machine runs AI coding agents almost around the clock, Claude Code and Codex, editing code, installing packages, running builds and tests.

I didn't go digging myself. I asked one line in a chat: "Why is my home PC lagging? Look at what's loading the CPU and disk and name the main cause. Don't change anything." The chat reached the computer, looked at processes and disks, and came back with two causes. I would have spent a long time finding either of them.

Cause one: Defender scans every file the agents write

Windows' built-in antivirus checks every created and modified file in real time. A person changes a few dozen files a day. An agent changes tens of thousands: package installs, builds, a separate copy of the project for every task. Defender opens and scans each one. In Task Manager it shows up as "Antimalware Service Executable" eating CPU while you seem to be doing nothing.

How to check by hand. In an elevated PowerShell, record Defender's work for a couple of minutes:

New-MpPerformanceRecording -RecordTo C:\Temp\defender.etl
# let your agents work for a couple of minutes, then press Enter
Get-MpPerformanceReport -Path C:\Temp\defender.etl -TopProcesses 10 -TopExtensions 10 -TopFiles 10

The report shows whose files took Defender the longest. If node, git and your project folders are at the top, that's your answer.

Two ways to deal with it:

Exclude the agents' working folders from scanning. The price is clear: Defender won't catch anything in those folders any more. Agents download packages from the internet, so exclude only code folders, not Downloads and not a whole drive.
Windows 11 has a Dev Drive, a separate volume for development work. Defender scans it in a lighter mode that doesn't hold up writes. It's a middle ground between "scan everything" and "scan nothing".

We took the first route and went a bit further. We excluded the working folders where agents create files, and the agent programs themselves: Claude Code, Codex, Antigravity, Cursor.

Add-MpPreference -ExclusionPath "D:\Work"
Add-MpPreference -ExclusionProcess "C:\path\to\agent.exe"

Excluding a program is a bigger step than excluding a folder. Defender stops scanning the files that program opens and writes, in any folder. Agents pull other people's packages from the internet, so I took that risk on purpose: it's a work machine, and the lag was costing me more. If that's not true for you, start with folders only, or with a Dev Drive.

Cause two: the agents wrote to drive C even though they were told not to

Every one of my agents has the same line in its instructions: work on drive D only. The projects really are on D. And yet the system drive C kept filling up.

It turned out it wasn't the agents writing there, it was the programs they run, and the agent apps themselves: package caches, app data, temp files. By default all of that lands in the user's AppData on drive C. The agent honestly works in D:\, and the gigabytes pile up in C:\Users\…\AppData.

This is the part worth remembering: an instruction controls what the agent does, not where the programs it launches write.

How to see which AppData folders are the biggest:

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

On my machine the top entries were the npm cache (including the npx cache, which lives inside it) and Docker's data. Agents run all sorts of things through npx, and every version stays in the cache. We cleaned up like this:

npm cache clean --force          # npm cache, including packages fetched by npx
docker system df                 # how much images, containers and build cache take
docker system prune              # remove stopped containers and anything unused

Cleaning treats the symptom: in a month the caches grow back. So we also moved the folders themselves to D and left a link on C pointing to the new place. Programs still write "to AppData", while the files physically live on D. Close the program that owns the folder first:

robocopy "$env:LOCALAPPDATA\SomeTool" "D:\AppData\SomeTool" /E /COPY:DAT
Rename-Item "$env:LOCALAPPDATA\SomeTool" "SomeTool.old"
cmd /c mklink /J "$env:LOCALAPPDATA\SomeTool" "D:\AppData\SomeTool"
# check the program still works, and only then delete SomeTool.old

Some programs offer a cleaner route: tell them to keep their cache elsewhere. For npm, for example: npm config set cache D:\npm-cache.

The result

CPU load dropped from 67% to about 12%. No new hardware, no reinstall: Defender simply stopped re-scanning files we were creating ourselves. The PC stopped lagging, and I went back to work.

What I took from it

A computer running agents is a different kind of load. It writes files hundreds of times more often, and anything that inspects files starts to drag.
Checking what the agent does isn't enough. Check where the traces of its work end up.
You can hand the diagnosis to an AI in one question. Just add "don't change anything" and ask what the conclusion is based on.

I asked through Local Commander, my own project, which lets a chat reach my computers. But both checks above take half an hour by hand without it.

Have your agents ever slowed a machine down in a way you had to hunt for?

We reverse-engineered a low-code platform's "Check" button and put its widget code in git

Peter Mamrukov — Mon, 26 Oct 2026 18:42:25 +0000

Low-code platforms promise you will barely write code. That holds for a few months. Then you have dozens of forms, several people editing them, and someone who "just tweaked a script in production". It turns out you are doing software development after all, only without git, without review and without a way to roll back.

I lead a business applications team in a holding company. We build modules for contracts, counterparties, correspondence and powers of attorney on ELMA 365, a low-code BPM platform popular in Russian-speaking markets. Part of the code is written by AI coding agents. This post is about the pipeline we built to get widget code out of the browser and into a repository, and the traps we found on the way.

The starting point

In ELMA 365, almost everything is configured in a web designer: forms, fields, processes, permissions. Widgets carry TypeScript scripts. Client scripts run in the user's browser, server scripts run on the platform. You write them in a code editor inside the designer, press "Check", press "Publish", done.

That works for one developer. For a team where AI agents write code, it is a dead end. An agent needs a file. A reviewer needs a diff. A manager needs to know what changed on Tuesday.

The platform ships a CLI that exports a solution to files. Export works well: hundreds of files, forms, processes, permissions and scripts, all ready for git. Import is the problem. Label and form changes went back fine. As soon as a widget script changed, the import failed. We reproduced it on several platform builds. The official position is clear: widget scripts are written in the designer, and there is no documented path around it.

We could have accepted that. Instead we went to see what the button actually does.

Stopgap: a robot in the designer

While we investigated, work had to ship. So the first solution was an honest hack: a headless browser that logs in, opens the widget, pastes the code, and clicks Save, Check and Publish.

Every step cost an evening. The code editor auto-closes brackets, so typing code character by character produces garbage. You paste through the clipboard instead. You cannot verify the paste by reading the hidden textarea either, because it only mirrors the visible part of the file.

The worst surprise came after a platform upgrade. In the new UI, the Publish button stayed enabled even when Check had reported compile errors. A robot that looked at button state could have published broken code. We changed it to read the compiler's response instead of the UI.

One rule from that period is now a team policy: automate the UI only when there is no CLI or API. Browser automation is fragile, slow and breaks with every redesign. It is the last resort, not the first.

What "Check" really runs

Here is the chain on the server. The button sends the widget to the widget service. That service puts a "compile" job on a RabbitMQ queue. A Node.js worker picks it up. Inside the worker is a plain TypeScript compiler.

The interesting part happens before compilation. For each widget, the platform generates a type definition file describing the world the script lives in: the form's context and fields, the fields of the app the form is bound to, the server functions, the platform SDK. That is how the compiler knows your contract has a counterparty field and does not have counterpartyy.

Then it is a normal TypeScript program of two files: the generated definitions and your script. Any diagnostic rejects the script and nothing is stored. Otherwise the code is emitted. Client code gets wrapped in a function roughly like this:

export default function (Context, ViewContext, Server, System): any {
  // your code, imports stripped
  async function onInit() { /* ... */ }
  async function onSave() { /* ... */ }
  return { onInit, onSave };
}

Every top-level function is returned so the platform can call it. Server code is transpiled in place. The platform also stores a description of each function's parameters, and those descriptions contain the literal string "[object Object]" where types should be, an artifact of how they are built from the syntax tree. Harmless, but if you want byte-identical output, you have to reproduce quirks like that too.

Running the compiler locally

If the compiler is ordinary, you can run it yourself. We did.

The per-widget type definitions come from the same request the designer itself makes, with a normal login. No tokens are pulled out of the browser. The compiler is the public typescript package pinned to the exact server version, with the same options. A test fails if the version drifts. The wrapper and emit steps were ported line by line.

Then we had to prove it was the same compiler, not a similar one. We took the whole contracts module, all 74 widgets, compiled each one locally, sent the same sources to the server's own check, and compared byte by byte.

The first run showed type errors in ten widgets. They were not bugs in the code but gaps in our understanding of how the server builds the type definitions. For example, for a form bound to an app, fields come from the app, and the form's own fields arrive as an extra context. Each rule cost one failing widget. Once the rules were complete, all 74 matched. Deliberately injected errors (a string assigned to a number, a call to a missing server function, a wrong return type) were reported by both sides at the same position.

Seven stock widgets stored compiled code in an older wrapper format. When we sent them to the server compiler, it produced our output, so that code was simply built by an older platform version.

We also found a blind spot in the server's own Check: it builds the list of server functions from what is already saved, not from the submitted code. A brand-new server function looks like an error during the first check, even though it publishes and runs fine. Our tool recognizes that exact pattern and says so.

"There is no signature"

Why couldn't a package with a tiny manual edit go back in? Our first guess was a signature.

It wasn't. We changed one letter in a panel title. The edited package passed server validation. The only hashes in the package protect the "paid" and "locked" flags, so a paid solution cannot be flipped to free. Form and script content is not covered. We even flipped a character in the company identifier inside the package. Nothing changed.

The real gate is version identity. Every solution has an authoring server, where it was created, and target servers, where it is installed. On a target, import gives the widget a fresh internal ID and new versions land cleanly. On the authoring server, import matches the existing widget and tries to write a new version whose ID is derived from the version number. That record already exists, so the server reports a collision.

So: the server that authored a solution refuses a new version of its own widget from a file. The same package installs fine where the solution is merely installed. That is not tamper protection. It is an identity rule, and it should shape how you arrange your environments.

The silent success trap

The next traps don't fail. They pretend everything is fine.

Each object in the package carries a version history. If you change an object without adding a new history entry, the import sees a match with the server and silently skips it. Exit code zero, task successful, nothing applied. Pre-validation doesn't help: it is equally happy with a package that will apply, one that will be skipped, and one that will collide.

Worse, the server does not recompile on import. It stores the compiled code from the package as-is. Fix the source but skip the compile, and the designer shows your fix while the form runs the old code.

Two rules came out of this:

After every install, export again and diff against what you sent. Exit codes are not proof.
Run the local compiler in verify mode in CI. It writes nothing and fails if any widget's compiled code does not match its source.

The vendor update that would have deleted our work

A supplier sent a new build of the contracts module to install over ours. Before installing, we exported the live solution and diffed the forms. The sidebar of the contract card had eleven blocks; so did the update, but different ones. The block containing our custom document-list widget was simply not there. Installed as is, the customization would have quietly vanished from the form.

No bad intent: the supplier didn't know about our change. But the rule is now fixed. Before installing any update package, diff the live forms. An update is a full new version of a form, not a patch.

The pipeline today

export solution from the environment
        |
edit .ts source in the repo (human or agent)
        |
compile locally against that environment's types
   |- type error -> nothing written, fix it
   |- ok -> compiled code regenerated, version entry added
        |
review the diff: source + compiled code
        |
install on the test server
        |
export again, compare with what was sent
        |
commit what is actually live

Before installing, the tooling snapshots the target. Rollback goes through files too, with a twist: a raw old snapshot is refused because its version history is older than the server's. So rollback takes the content from the snapshot, the history from the server, adds a new entry, and verifies by exporting again.

Environments have roles. A sandbox we fully control for experiments. A shared development server for business work. Then test and production, where a partner company transfers changes through its own process. Production is read-only for our agents. Before anything goes to the shared server, a candidate is installed on an isolated environment and the whole affected business route is exercised with real form buttons. A successful publish response only proves the request arrived.

Finished changes go into a simple register. One card per change: what changes, how to check it on test, how to confirm it on production read-only. Statuses: waiting for transfer, on Test, on PROD, or cancelled. Boring, and it stops finished work from sitting forgotten for two weeks.

CI for our own tooling

Around this pipeline we built an internal team web service, our Wiki. Agents work on it too, so its CI is stricter. Every push and pull request runs the tests, then a set of real-browser checks walks through the pages, and their screenshots are kept for a week.

The production update command only runs from a clean main branch and ships an archive of exactly the committed revision. It builds and tests on the host while the old service keeps running, and stops the old one only after the new one passes. It takes a backup, keeps the previous container for rollback, checks health and HTTPS afterwards, and restarts the old container if activation fails. It connects only to a host whose key is already known and refuses unknown or changed keys. No secrets go into the repo, the command line or the release archive.

What I took away

Low-code is development. Once you have more than one developer, or a single AI agent, you need files, diffs, review and repeatable installs.

"No documented path" doesn't always mean "no path". Sometimes it means looking at what the button does. Behind ours was an ordinary TypeScript compiler, and we could reproduce it honestly, without bypassing any protection.

And the most dangerous failures are the quiet ones. We no longer trust buttons or exit codes. We trust the re-export and the diff.

We reverse-engineered a low-code platform's "Check" button and put its widget code in git

Peter Mamrukov — Mon, 26 Oct 2026 15:41:34 +0000

The starting point

That works for one developer. For a team where AI agents write code, it is a dead end. An agent needs a file. A reviewer needs a diff. A manager needs to know what changed on Tuesday.

We could have accepted that. Instead we went to see what the button actually does.

Stopgap: a robot in the designer

While we investigated, work had to ship. So the first solution was an honest hack: a headless browser that logs in, opens the widget, pastes the code, and clicks Save, Check and Publish.

What "Check" really runs

export default function (Context, ViewContext, Server, System): any {
  // your code, imports stripped
  async function onInit() { /* ... */ }
  async function onSave() { /* ... */ }
  return { onInit, onSave };
}

Running the compiler locally

If the compiler is ordinary, you can run it yourself. We did.

Seven stock widgets stored compiled code in an older wrapper format. When we sent them to the server compiler, it produced our output, so that code was simply built by an older platform version.

"There is no signature"

Why couldn't a package with a tiny manual edit go back in? Our first guess was a signature.

The silent success trap

The next traps don't fail. They pretend everything is fine.

Two rules came out of this:

After every install, export again and diff against what you sent. Exit codes are not proof.
Run the local compiler in verify mode in CI. It writes nothing and fails if any widget's compiled code does not match its source.

The vendor update that would have deleted our work

No bad intent: the supplier didn't know about our change. But the rule is now fixed. Before installing any update package, diff the live forms. An update is a full new version of a form, not a patch.

The pipeline today

export solution from the environment
        |
edit .ts source in the repo (human or agent)
        |
compile locally against that environment's types
   |- type error -> nothing written, fix it
   |- ok -> compiled code regenerated, version entry added
        |
review the diff: source + compiled code
        |
install on the test server
        |
export again, compare with what was sent
        |
commit what is actually live

CI for our own tooling

What I took away

Low-code is development. Once you have more than one developer, or a single AI agent, you need files, diffs, review and repeatable installs.

And the most dangerous failures are the quiet ones. We no longer trust buttons or exit codes. We trust the re-export and the diff.

A read-only first week: three questions to ask your computers

Peter Mamrukov — Sat, 24 Oct 2026 11:47:29 +0000

Originally published at localcmd.app/use-cases/read-only-first-week.

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

Exit code, stdout, stderr: the three answers a command gives you, and the one it doesn't

Peter Mamrukov — Sat, 24 Oct 2026 07:19:31 +0000

Every program you run hands back three separate things. People read them as one. That is the whole bug this article is about.

stdout: normal output. Results, progress, "started".
stderr: the error stream. Warnings and failures, if the author sent them there.
exit code: one integer when the process ends. 0 means "I did not report a failure". Anything else means "I did".

They are independent channels. A program can print cheerful text to stdout and exit non-zero. It can print nothing and exit 0. It can write to stderr and still exit 0 (many warnings do exactly that). None of the three tells you whether the thing you wanted now exists. Let's make that concrete.

A program that disagrees with itself on purpose

Save this as app.cjs. It writes a "started" line to stdout, then notices a required file is missing, complains on stderr and exits with 42.

// app.cjs
const fs = require("node:fs");

console.log("started synthetic-report");

if (!fs.existsSync("required-config.json")) {
  console.error("CONFIG_MISSING: required-config.json is absent");
  process.exitCode = 42;
}

Run it in a folder without required-config.json. I did this on Windows 11 with Node.js 22; the behaviour is the same on macOS and Linux.

In bash

node app.cjs
echo "exit: $?"

Output:

started synthetic-report
CONFIG_MISSING: required-config.json is absent
exit: 42

Both lines land in the same terminal, so by eye they look like one message. They are not. Prove it by splitting the streams:

node app.cjs 2>errors.txt     # stderr goes to a file, stdout stays on screen
echo "exit: $?"
cat errors.txt

In PowerShell

node app.cjs
"exit: $LASTEXITCODE"

Same two lines, exit: 42. Note the variable: for a native program, $LASTEXITCODE holds the exit code. $? only tells you whether the last PowerShell statement succeeded, which is a different question and a common trap in scripts that mix the two.

The interpretation mistake

Here are three ways people turn that 42 into "it worked".

1. Reading stdout as the verdict. The first line says started. A script that greps for started, or a person skimming, sees success. stdout is narration, not a verdict.

2. Losing the exit code in a pipe. In bash:

node app.cjs | tee run.log
echo "exit: $?"      # 0

That 0 is tee's exit code, not the app's. A pipeline's status is the status of its last command. Fix it with set -o pipefail at the top of the script (then the pipeline fails if any stage fails), or read ${PIPESTATUS[0]} right after the pipe.

PowerShell has the same shape:

node app.cjs | Tee-Object run.log
"exit: $LASTEXITCODE"   # still 42 here, because node was the last *native* command

PowerShell keeps $LASTEXITCODE from the last native executable, so this particular pipeline is fine, but as soon as you wrap the call in a function or a try block, check that the code is actually propagated and not swallowed.

3. Trusting the wrapper's own exit. Suppose a script runs the app and then writes a report:

// run.cjs
const { spawnSync } = require("node:child_process");
const r = spawnSync(process.execPath, ["app.cjs"], { encoding: "utf8" });
console.log("report written");

node run.cjs exits 0. The wrapper is telling the truth about itself: it did write a report. The child exited 42, and nobody looked. This is how CI steps, deploy scripts and AI assistants end up saying "done" over a failure. The wrapper has to carry the child's verdict forward:

const r = spawnSync(process.execPath, ["app.cjs"], { encoding: "utf8" });
console.log(JSON.stringify({ exitCode: r.status, stdout: r.stdout, stderr: r.stderr }, null, 2));
process.exitCode = r.status ?? 1;   // null status means the child was killed by a signal

Now the report contains all three channels, and the wrapper's own exit code is honest.

The check that answers the real question

Even a perfectly captured 42 only tells you what the process thought. Your question was different: did the report get produced? Did the files get copied? Did the service come back up? The exit code is evidence about the process. The result needs its own check, against the artifact you wanted.

Suppose app.cjs was meant to write report.json (our synthetic one never gets that far). Then the real check is:

node app.cjs; code=$?
if [ "$code" -ne 0 ]; then echo "process failed: $code"; exit "$code"; fi
test -s report.json || { echo "process exited 0 but report.json is missing or empty"; exit 1; }

node app.cjs
if ($LASTEXITCODE -ne 0) { throw "process failed: $LASTEXITCODE" }
if (-not (Test-Path report.json) -or (Get-Item report.json).Length -eq 0) {
  throw "process exited 0 but report.json is missing or empty"
}

Two checks, in that order. First the process's verdict (exit code, with stderr next to it so the failure has a name). Then the artifact: does the thing exist, is it non-empty, does it have the rows or files you expected. The second check is the one people skip, and it is the one that catches "exit 0, wrong result": a copy with the right file count and one changed file, a build that passed with the old bundle still on disk, a service that started and then died.

The habit

Print all three channels, as data, before you summarise. "It said something about config" is not evidence; CONFIG_MISSING, exit 42 is.
Never let a pipe or a wrapper eat the exit code. set -o pipefail, ${PIPESTATUS[0]}, $LASTEXITCODE, process.exitCode = child.status.
Name the artifact before you run, and check for it after. A clean exit code is a reason to look, not a reason to stop.
Treat a missing number as missing. Truncated output, no exit code captured, a timeout: that is "unknown", not "probably fine".

Try the two-line app.cjs in your own shell and in whatever runs your scripts for you. If you find a place where the 42 disappears between the program and the summary, that is the bug worth fixing first.

Author note: I'm Peter. I build a tool that lets a chat run commands on your own computers, and this exact mistake is why I insist on seeing all three channels; the read-only checks I start with are at https://localcmd.app/use-cases/read-only-first-week.

How to connect ChatGPT or Claude on the web to your own computer, without opening a port

Peter Mamrukov — Fri, 23 Oct 2026 11:05:19 +0000

You got a local MCP server working. Claude Desktop sees it, your editor sees it, and the model runs your build without you pasting anything. Then you open ChatGPT in a browser tab, or Claude on your phone on the way home, and the tools are gone. The chat is right there, the computer is right there, and the two never meet.

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:

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.
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.
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.
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:

Install. On each computer, run npx local-commander-agent@latest. You need Node.js 20 or later, on Windows, macOS or Linux.
Approve. Confirm the pairing in your browser at localcmd.app.
Choose access. Your whole user account, which is the default once you approve, or only the folders you pick.
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.

How to run one task on all your computers from a single ChatGPT or Claude chat

Peter Mamrukov — Fri, 23 Oct 2026 09:03:24 +0000

Few people who work with computers have just one. There's the work machine, the PC at home, maybe a small server or a cloud VM, and a parent's laptop in another city that only gets attention when it breaks.

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

Install. On each computer, run npx local-commander-agent@latest. You need Node.js 20 or later.
Approve. Confirm the pairing in your browser.
Choose access. Your whole user account, which is the default once you approve, or only the folders you pick.
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.

Why your coding agent keeps breaking on Windows, and four fixes that hold

Peter Mamrukov — Sun, 18 Oct 2026 08:44:51 +0000

For a while my workflow with AI was: the chat suggests a fix, I paste it into the terminal, run the tests, copy the error back. I was a very slow USB cable between the model and my Windows PC. Agent modes were supposed to end that. On Windows they often don't, and the reasons are fixable.

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.