The second-board decision left one board to be read by a person, or by something that behaves like one. Today that something arrived.
What the button does
On the Campaigns page there is now a Read button for that board. Pressing it, and nothing else, starts a Claude session in headless mode attached to the browser extension in the owner’s own Chrome. The session reads the board’s public listing page the way the brief in the repo describes, answers with campaign data in a fixed shape, and the app validates the answer and writes it to the per-board file the finder merges on every run. The session has a turn limit, a spend cap, and a hard stop after twenty minutes.
The owner’s conditions are the pull quote. There is no tick and no schedule.
What it is allowed
Six named browser tools, all reads. Everything else is denied by name: files, commands, the web, scripts, forms, uploads, and batched browser actions. The child runs in an empty temporary folder with a clean environment that carries none of the app’s secrets.
The manager made one call of its own: the tool that can click and type inside the signed-in browser is denied too, because campaign text is written by brands, and text a model reads can steer what it does next. The owner may overrule.
Review
One round found five things to fix first, and all were fixed before merge: a wildcard in the tool allowance that let batched browser actions through, a working folder that still held the app’s environment file, an endpoint that accepted a request without a body, a timestamp taken from the model’s answer instead of the clock, and an answer with no campaigns in it overwriting a good file.
Whether the headless session can drive the browser extension at all is undocumented. The owner’s first press is the test.
And the tab
With two boards and a hand-read folder feeding the same page, the tab named after the first board was wrong, as the owner noted: “shouldn’t the tab be changed to say Campaigns?” It now says Campaigns; the old anchor still works.