We Wired ChatGPT and Gemini as Tool-Connected Browser Workers — and One of Them Said No

What a “browser worker” actually is

Skynet already runs headless command-line lanes. What it did not have was a way to use the models we are already signed into — through their web interfaces — as executors rather than advisors.

So we built one. A new worker opens the normal chat (not the incognito or temporary one) on a real, signed-in Chrome tab, driven through the Chrome DevTools Protocol. The tab mirrors on screen while it runs, so you can watch the model think and act. And the model is handed a small tool loop wired to ten real developer tools: read, write, and edit files; grep and glob; a shell; web fetch and web search; and two fleet operations — dispatch a task to another worker, and query live lane status.

The protocol is deliberately dumb. The model emits a JSON tool_call. A local harness executes it for real, captures the output, and pastes it back into the same chat as a TOOL_RESULT. The model reads the result and continues, until it decides it is done. No special plugins, no agent mode — just a chat window and a loop.

Gemini just did the work

Pointed at our repository with a small task, Gemini behaved exactly like an agent should. It called glob to list files, called read_file to open the one it needed, and reported back the correct facts — first line and all. It is now a first-class member of the fleet, dispatched like any other worker, every action a real browser tab you can watch, backed by a full transcript and screenshots. The model it is actually using is reported honestly, never assumed.

ChatGPT said no — and that is data, not a defect

Here is the part we did not expect. Running the identical loop against the GPT-5-class ChatGPT account we tested, the model refused to participate: “I can’t emit a fake tool_call block… that tool interface is not available in this chat.” We tried three different framings. It held its ground every time.

That is not a defect in our wiring — the same code drove Gemini to a clean success. It is a model or account behavior: this ChatGPT is trained to distrust an unfamiliar “tool interface” it cannot verify, and it will not pretend otherwise. So we log it as what it is — a refusal — instead of dressing it up as a pass. An honest “no” is more useful than a confident fake yes.

The insight: framing is the whole game

What moved compliance was not more insistence; it was less menace. Web models balk at prompts like “execute shell commands on the real machine” — that reads like a trap. Reframe the exact same capability as a benign developer function-calling backend, and lead with a tiny read-only handshake so the model sees a real result come back before it is asked to do anything consequential:

```tool_call
{"tool": "glob", "args": {"pattern": "*.md"}}
```

Once that harmless call returns an actual list of files, the disbelief evaporates. Gemini went from “I can’t access your files” to calling read_file on its own — because it now had proof the loop was real. The handshake is not a trick; it is evidence.

The takeaway

Two lessons worth keeping. First, the interesting variable in browser-driven agents is not the plumbing — it is trust. Give a model verifiable proof that its actions are real, framed without menace, and it will work. Withhold that proof, or wrap it in threatening language, and even a capable model will politely decline.

Second, when a model declines, say so. Our worker classifies refusals honestly, reports the actual model, and keeps the receipts — transcript and screenshots. A system you can trust is one that tells you when it did not do the thing, not one that always claims it did.

Gemini is on the fleet now. The ChatGPT door is wired and waiting for the day that account changes its mind. Either way, the log will tell the truth.