helloim.ai: building a Windows desktop application, and the one check its release waited on

The problem

The application points a coding assistant at a folder on a person’s own machine, gives it a voice, and lets them talk to it out loud, not just type. 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, a folder that gets its own instructions obeyed before anyone has agreed to it, and a name that quietly failed to travel with the folder it was supposed to travel with.

All four 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. How that runs, in more detail →

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 [the application]”

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:

Run against a target held open under an exclusive file handle

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 the application 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.

The folder that already had a name

A name written into a folder should make a second machine recognise it. Twice, it did not.

Name an assistant once and the application is meant to carry that name to any folder it works in — point it at a folder synced to a second machine and the assistant should already be there, under the name it was given on the first. Two separate faults broke that promise, in opposite directions, and both were found the same week.

The setup wizard asks for a name in its first few steps, before it has looked at the folder the person is about to pick. The folder, carrying a name it already adopted, arrives five steps later. Until the fix, the later answer lost: the wizard’s own guess overwrote the name already sitting in the folder, and rewrote the folder’s own record to match it. Somebody who had already named their assistant on one machine was made to guess a name for it on the second, and then watched that guess stamped over the name they had already given it.

Fixed by ordering, not by asking. An adopted name now wins over one typed at setup, and typing a name only ever fills a name that is still blank — it never overwrites one that is not. Verified in both directions, plus the case where there is no folder to adopt a name from at all, and the case where somebody genuinely wants to rename their assistant later.

The second fault was quieter. A folder’s saved name lives in one small file, and a file written by a common tool’s default text encoding carries three invisible bytes at its start — a byte-order mark. The code reading that file treated the mark as a broken document and refused to read any of it, which looks identical to a folder that never saved a name in the first place. Nothing failed loudly. The name was simply never offered, and the folder looked ordinary.

The mark is now read and discarded rather than treated as damage. And the fix drew a line the first version never had: a manifest that genuinely cannot be read — truncated, not JSON at all — now shows a short notice on screen instead of closing quietly. Silence was the actual bug. A file that fails should say so.