The problem
NameOS points a coding assistant at a folder on a person's own machine and lets them talk to it. That is the whole product, and it is also the whole risk: the folder can carry instructions, and the person is not a developer who will read them first.
It is packaged as a Windows installer for people who will never see a terminal. So the failures that matter are not compile errors. They are an installer that reports success and does nothing, a page that asks for legal assent to a document that is not there, and a folder that gets its own instructions obeyed before anyone has agreed to it.
All three happened. Each one is below.
The approach
Design, implementation, adversarial review, release verification and independent sign-off are separate passes run by separate agents, and no agent reviews work it had a hand in. The reviewing agents are read-only by design: they find and prove, and whoever built it repairs it.
Claude Code runs each of those passes. What it does not do is decide when something is finished — that is settled by a command, on a real machine, or it is not settled.
The licence page that had no licence
A licence page asked for legal assent to a 72-byte file.
A review agent with no part in the work read the finished installer cold.
It found a licence page asking for consent to a document that did not exist. In front of an I Agree button, the installer said:
- “Please review the license terms”
- “Press Page Down to see the rest of the agreement”
- “You must accept the agreement to install NameOS”
The file behind it was 72 bytes: the product name, a tagline, and one sentence saying the installer installs the product. Not terms. Marketing copy under a page requesting legal assent — and it would have been in front of every person who ever ran the installer.
Nothing was written to replace it. Real terms are a decision for the company, not for an installer file, and an installer with no licence page at all is entirely ordinary — most are exactly that. The page was removed, which is a complete fix rather than a placeholder for one.
The same pass also caught a duplicated phrase in the welcome text. One finding was legal and one was a repeated word, and both came from the same mechanism: a reader who had no stake in the work and had not watched it being built.
That page had survived every earlier pass over the same file. It was caught by the first reader who had not made it.
The update that reported success and did nothing
A broken update path passed ten test runs out of ten.
It exited zero, wrote the new version number into Add/Remove Programs, and left the old binary on disk. No error and no pending rename, so it would not repair itself at the next reboot. The registry said more than the disk did, and that machine would be offered the same update forever.
It had passed on a clean rig every time, because the fault needs a file lock a clean rig does not produce. The verification pass said so plainly: the campaign was worthless, and clean runs proved nothing.
So it stopped waiting for the failure and manufactured it. The update was run against a target held open under an exclusive file handle, alongside a control built from the pre-fix script for comparison:
| Control | exited 0, claimed version 0.2.0, left 0.1.0 on disk. |
|---|---|
| Fixed | exited 2, claimed nothing, left the existing install working. |
Verified on a physical Windows machine on 29 August 2026.
The fix does not try to win the race. Overwriting a running executable is blocked; renaming one is not, because a rename is a directory operation rather than a write. The running binary is renamed aside and the new one written under its own name — proven six times in a row against the same locked target that had just refused a direct overwrite. If the write fails anyway, the original is put back, nothing is written to the registry, and the installer exits non-zero so nothing downstream can call it a success.
A longer wait would have narrowed that window without closing it. It would have failed at a different rate on a different machine, which is the same bug wearing a better disguise.
Trusting a folder
A folder can carry instructions. Nothing asks first, so the person decides.
An adversarial review agent was pointed at the application's own process spawn and asked to break it. It did, twice.
A CLAUDE.md sitting in a folder is read on turn one, with nobody asked. A
.claude/settings.local.json that arrives with a folder is treated as the
user's own and its rules are applied — the agent used one to run a command that read the
machine's account list, unprompted.
Both are documented behaviour, verified here against the installed binary rather than taken from the page: the workspace trust dialog is skipped in non-interactive mode, and the permissions documentation gives the row-by-row detail for a folder that was never trusted. A folder that arrives by download, share or sync brings its instructions with it, and "point it at a folder" is the product — so this is the threat model, not an edge case.
No flag closes it. The settings files can be dropped; CLAUDE.md cannot be,
because that is the same file NameOS writes the user's own profile into. A "work here but
ignore this folder's instructions" button would be a lie. There are two honest answers —
accept the folder, or do not work in it.
So the decision was moved to the person. Before anything spawns, the folder is probed for the files that carry instructions or configuration into a run, and the send is refused until someone has looked at the list and accepted it.
Four properties are worth naming, because each one is a way this could have been built wrong:
- Failing to probe is never trust. A folder that cannot be read comes back untrusted, with the decision outstanding. It never comes back clean.
- The record lives with the application, never in the folder. A trust record written inside the folder would ship with the folder.
- A file that appears after acceptance re-opens the decision. A file that is deleted does not. Something synced in afterwards is new to consent to; something removed is less.
- A folder reached through a symlink is recorded as its target. Otherwise trusting one path would silently trust wherever it was later pointed.
The probe walks no trees. It is a fixed handful of file checks, because a person may point this at a folder holding a million files.