AI Helper tests in TEMP windows before it saves anything
An AI that can edit your configuration is only useful if you can trust it not to surprise you. JustZix's AI Helper is built around one rule: it shows you everything before it commits anything. This post is about that design — the "test, then confirm" model — and why it's the difference between a helpful assistant and a risky one.
The problem with "just let the AI do it"
It's tempting to let an assistant create rules directly. It's also a bad idea. A model can pick an over-broad selector, hide more than you wanted, or scope a rule to * when you meant one domain. If that change is written silently, you find out when something breaks — and you don't know which of the AI's edits caused it.
AI Helper avoids this entirely. It can propose and test freely, but it cannot save without you. Two mechanisms enforce that: TEMP windows for testing, and explicit confirmation for persistence.
TEMP windows: a sandbox you can see
When AI Helper wants to try code, it doesn't write it into a real rule. It calls open_temp_pane to open a TEMP CSS or JS window — the same in-tab developer window you'd open by hand — then set_temp_pane_code to insert its code there. A TEMP window is, by definition, not saved: it applies to the current tab only and disappears when you're done with it.
Crucially, you watch the code appear. The window is on screen, the code lands in it character by character, and the page reacts live. There is no hidden step. If the model's CSS hides the wrong thing, you see it in the same instant the model does.
Why "visible" matters more than "reversible"
Plenty of tools let you undo a change. That's good, but it's reactive — you undo after something went wrong. A visible sandbox is proactive: the bad change never reaches your saved setup at all. The TEMP window is a fitting room. You try the outfit before you buy it; you don't buy it and return it.
Every creation is a separate, explicit confirmation
Testing is free. Saving is not. AI Helper has exactly three tools that change your stored setup, and each one triggers its own confirmation dialog:
| Tool | What it creates | Confirmation |
|---|---|---|
create_folder | A new folder | Separate, explicit |
create_group | A new group inside a folder | Separate, explicit |
create_rule | A new rule with CSS/JS | Separate, explicit |
"Separate" is the key word. If a task needs a new folder, a group inside it and a rule inside that, you get three confirmations, not one bundled "approve everything". You can approve the folder and group but reject the rule, or vice versa. The model cannot batch a surprise into a yes you gave for something else.
What the confirmation shows you
A confirmation isn't a vague "the AI wants to make changes". It shows the concrete payload: for a rule, the name, the URL pattern, and the full CSS/JS body. You read the actual code before it's stored. If the URL pattern is too broad, you see it right there — and you decline.
The enforced workflow
This isn't left to the model's good intentions. The system prompt hard-codes the order of operations:
- Ask for details — clarify the goal before touching anything.
- Inspect the page — use
query_pageandlist_structureto work from facts. - Test in a TEMP window — open a pane, insert code, let you watch.
- Ask you to verify — explicitly hand control back: "does this look right?"
- Persist only after you agree — and only via a confirmed
create_*call.
So even an enthusiastic model proposing something aggressive runs into the same gate: it has to show you, then ask.
Tool calls are visible too
Every action AI Helper takes shows up as a chip in the conversation. Inspected the page? Chip. Opened a TEMP pane? Chip. You have a running, readable log of what the assistant did and in what order. There's no "trust me" — there's a trail.
Keys stay out of it
The safety model extends to your credentials. API calls go through the extension's background service worker, so your provider key never enters the page context and the request bypasses the page's CSP. The page you're modifying can't read your key, and the model can't reach your stored setup except through the three confirmed tools.
When you should still pay attention
The model isn't infallible. The system is built so a mistake stays contained in a TEMP window — but you're still the reviewer. Read the proposed code. Check the URL pattern. Reload the page during testing. The confirmation dialog is a real decision point, not a formality to click past.
See also
- Build a rule with AI Helper — see the test-then-confirm loop in a full walkthrough.
- The agentic tool-calling workflow — the 8-step loop and the full tool list.
- API keys: privacy and sync — where keys live and how the service worker isolates them.
Download JustZix — free, no account. An AI assistant that proposes, tests in plain sight, and saves only with your explicit OK.
Rate this post
No ratings yet — be the first.