Stop Being the One Who Clicks Around
You are the last step in the loop
You know this loop. You ask for a change, the agent writes it, the suite comes back green, and then you switch to the browser and click around to find out whether the thing actually works.
That last step is you. Open the preview, click the flow, look, decide. Ten seconds. Forty times an afternoon, and somewhere around the fortieth you have stopped looking carefully. I ran this loop for a year without ever deciding to.
Everybody optimizes the terminal: prompts, skills, models. Nobody optimizes the window below it, because it does not look like tooling. It looks like diligence. It is your eyes on your own app, re-checking work that was already reported as finished.
And it refuses to scale. Two agents means two streams of screens. Four means you are a QA department. Agent setups exist to run more work in parallel, and this one step caps all of it at one human.
Green suite, broken page
Nothing in that terminal changed. Same prompt, same diff, same eighteen passing tests. I clicked Remove, the cart emptied out with the total still reading twelve dollars, and when I pressed Checkout the page told me my payment had failed because there was nothing in my cart.
The unit test passed because the function it covers is correct. The total was seeded into component state once, at mount, and removing a line never touched it. There is no bad function here to catch. The bug lives in a sequence: render, remove, look.
The agent cannot see this, and I mean that literally rather than as criticism. It wrote the code, ran the suite, read the output, and every signal available to it says done. The one signal that would have caught the bug is a picture of the page after a click, and nothing in its loop takes pictures.
So I catch it, or nobody does. And catching it is only half the job. Then I go back to the terminal and type up what I saw, in my own words, in the box at the bottom of the window: what I clicked, what broke, which number is wrong. I am the tester and I am also the bug report. That is the deal, and I never actually agreed to it. I just kept clicking.
Hand the checking to another agent
The fix is not a better prompt. It is a second agent whose whole job is to open the thing, use it the way a person would, and say what it saw. Same change as before, same page. One step added, and the step is not mine. Nobody presses Checkout by hand this time, and nobody types up what happened when they did.
Watch the order. The builder finishes and, instead of handing the work to me, shells out to Codex with computer use enabled. Codex opens the page in a real browser, clicks Remove, takes a screenshot, reads it, and writes a report that says FAIL and names the number that is wrong. The builder reads that report, fixes the line, and asks for another run. The second run is green.
Two things make that worth doing rather than just asking the builder to check its own work. The verifier did not write the code, so it has no stake in the code being right. And it has hands. It is not reasoning about what the page probably renders. It is looking at what the page rendered.
My part of the loop is now reading a verdict. That is a thing I can do for four agents at once, on a phone, between other work. The loop that used to end at my eyes now closes between two machines, and I find out about it afterwards.
I never type any of this into a prompt. It is one rule in my global CLAUDE.md, so every session reads it before I say a word: “If computer use is helpful for completing or verifying work, shell out to codex for it.” The orchestrator decides when a change deserves the browser treatment, and I find out from the report.
Codex is the one that drives a computer
I will say this plainly. Right now Codex is simply the best tool I have used at driving a computer. Not marginally, not arguably. It navigates apps, recovers from weird UI states, notices things it was not told to look for, and comes back with evidence rather than a story. The models I reach for first on taste do not match it there today.
That is the jagged frontier doing exactly what it always does, and it is why my whole setup routes work by capability rather than by loyalty. I wrote the long version of that argument in the post about mixing labs. This is the sharpest single instance of it: one lab is meaningfully ahead at one thing, and that one thing happens to be the step I most want off my desk.
The report is the artifact. Four checks, two screenshots, one verdict, each screenshot described in words so the report stands on its own without me opening a single image. I read the failing line and the sentence under it, and I know more about the state of my app than I did after clicking around, because the checks are written down and the same four run again next time.
The trade is real and worth naming: this costs a couple of minutes and a pile of tokens per run, so it belongs on the flows that matter rather than on every keystroke. But the alternative is not free either. It costs me, and I am the expensive part.
Steal the skill
None of it is secret sauce , so here is the whole file, exactly as my agent loads it. Copy it into ~/.claude/skills/codex-computer-use/SKILL.md, or paste it to your agent and ask it to install the skill, which is what I would do. Claude Code reads the description at startup and loads the rest only when a task matches it.
Most of the file is about stance rather than commands. When to use a real verification run and when a typecheck would have done. Which sandbox level the run gets. Where screenshots and the report land. What the report has to contain before I will believe it.
The section worth reading twice is the one about whose cursor gets used. GUI runs also need full machine access, which is a real thing to say yes to. I run them on my own projects, on a machine where that is the deal I have already made with my agents, and I would think twice before pointing one at anything holding real accounts or real customer data.
The rest of the setup this belongs to, the rubric that routes work to the right lab and the two sibling skills that hand off implementation and review, lives in the multi-lab post. This skill is the one I would install first.
The general shape, past this one skill: every time you find yourself doing something repeatedly to check an agent’s work, that is a job description, and somebody should be hired for it. Usually not you. You want to be the one moving the project forward, not the one running the same five clicks for the fortieth time to find out whether the machine told you the truth.
If you found this helpful, share it: