The machine server is now something you choose

ArcFlare's machine server is the part that does things to your computer. It runs builds, starts dev servers, opens applications, takes screenshots, moves the mouse and reads the clipboard. Given a model and a goal, it is the difference between advice and work.

It is also a great deal to hand to a model that fits in 8 GB of VRAM, and until this release it arrived switched on, because installing ArcFlare installed it. That is no longer true.

Asked once, remembered

The first time it matters, ArcFlare asks:

Machine control
  ArcFlare's machine server lets a model drive this computer

  > Yes, install it     screenshots, apps, builds and tests
    No, models only     the agent keeps files, search and the shell

The answer is stored in ~/.arcflare/config.json and never asked again. You can change it whenever you like:

arcflare mcp enable
arcflare mcp disable

Declining is not a degraded mode. The agent keeps the tools that make it an agent — reading and editing files, glob, grep, the shell — and simply has no camera pointed at your screen.

One deliberate choice: undecided is not the same as off. Someone who upgrades and never sees the question keeps exactly what they had, and a command in a pipe cannot answer a menu, so the default only applies where nobody could have been asked.

A repo's .mcp.json is a list of commands

The second change is quieter and matters more.

ArcFlare looks for MCP configuration in the working directory before your home directory, which is the right order — a repo should be able to say which servers it needs. But connecting to a stdio MCP server is spawning it. So a .mcp.json in a cloned repository was a list of commands that ran on your machine the moment you typed arcflare agent in that directory: before the model was asked anything, with no prompt.

Now configuration from a directory is inert until you say otherwise:

That prints what the file would actually start — the commands, not just the server names — and records a fingerprint of it. If the repo later adds a server, changes an argument, or edits a header, the fingerprint no longer matches and it comes back for another look rather than inheriting the trust its earlier version earned. Your own config, in your own home directory, is yours and is not gated.

A repo whose config is withheld still gets a working agent. It just gets one without that repo's servers, and a line on screen saying so.

What the fingerprint covers

Everything that decides what runs or what gets handed over: the command, its arguments, the URL, the environment block, the working directory — and, less obviously, headers and token.

Headers start nothing, so it is tempting to leave them out. But they are expanded against your environment on the way out, which means a single line added to a server you already trusted:

is a credential leaving your machine without one byte of the command line changing. They count.

And a bug worth naming

While we were in here, a real one: the screenshot and focus tools took a window title and interpolated it into the PowerShell they generate. The title was escaped for the pattern it is matched against — and then used again in an error message, which is a double-quoted PowerShell string, where $(...) is evaluated.

A window title was therefore a place to run code, and the thrown message handed the output back to the caller. A title matching nothing was enough to trigger it.

The fix was not better escaping. Escaping is exactly what failed: the value lands in two kinds of context and the right answer for one is wrong for the other. Every caller string now travels as base64 and is decoded into a variable inside the script, because base64 has no character the parser reacts to. From there "$title" interpolates the value without re-parsing it.

The regression test asserts the property rather than the patch: a title of $(7*6) has to come back as $(7*6), and never as 42.