How I AI: 4 Hands-Free Workflows Using Codex Browser Automation
I walk through my daily hands-free AI workflows, showing you exactly how I use Codex browser and computer use to QA my app, conduct persona-based research, manage my LinkedIn inbox, and even go shopping.
Claire Vo
Full episode
Watch or listen
Workflows from this episode
- Automate LinkedIn Inbox Triage with AI Browser Automation
- Conduct AI-Powered User Research by Impersonating Personas
- Automate Web App QA Testing with AI Browser Automation
Episode outline
I used Codex browser automation on four tasks I usually procrastinate on: QA testing, persona research, LinkedIn cleanup, and vacation shopping. The interesting part was not that the agent could click around a browser. It was how much tedious navigation, scrolling, resizing, filtering, and form filling disappeared once I gave it a clear outcome and stayed in charge of the judgment calls. See Automate Web App QA Testing with AI Browser Automation.
In this episode of How I AI, I treat Codex less like a chatbot and more like an operator sitting at the keyboard. Browser use lets it work inside a browser session, while computer use extends that control to the wider desktop. It can move through multi-step tasks, document what it did, and pause when a login, CAPTCHA, or ambiguous decision still needs a human.
The workflows that work best all share the same shape: repetitive actions, a visible finish line, and easy human review afterward. These examples also make the limits clear. The agent is great at persistence and exhaustive checking. It still benefits from guardrails, supervision, and clear instructions about when to hand work back.
Testing a real onboarding flow instead of the happy path
Browser automation is especially useful for QA because it interacts with the product the same way a customer would. Instead of inspecting code or manually spot-checking screens, I use Codex to move through ChatPRD onboarding in the browser and actively try to break things.

Setting up the browser agent
I run Codex through the desktop app with browser permissions enabled. Depending on the command, the agent can work inside its embedded browser, take over my active Chrome session, or use broader desktop controls through computer use.
For this QA pass, I opened a local version of the ChatPRD onboarding flow and asked the agent to test usability and mobile responsiveness while documenting every issue it found with screenshots and notes.
@browser to test the open onboarding flow for usability and mobile responsiveness. Please screenshot as you go, make a Google spreadsheet of any issues you identify.
The command prefixes matter. @browser points the task to the browser inside the desktop app. @Chrome gives the agent access to the active Chrome window and all the state already loaded there. @computer expands the scope beyond the browser so the agent can interact with desktop apps and operating system controls.
What the automated QA uncovered
The agent resized viewports, opened menus, switched device sizes, and repeatedly moved through the onboarding flow across different layouts. That sounds basic, but it exposed a blind spot in how I normally test. Human QA often follows the intended route: fill out the form correctly, click continue, confirm the success state, move on.

The browser agent spent far more time exploring edge cases and failure states. It found a high-severity onboarding bug where a user could skip a required selection, continue forward anyway, and end up trapped in a stalled state without a useful error message. It also identified smaller layout and usability issues involving overflow, touch targets, accessibility, and responsive behavior on mobile screen sizes.
At the end of the run, Codex generated a Google Sheet containing 11 documented issues with screenshots and reproduction steps. The value was not just finding bugs. It was getting a structured evidence trail after an exhaustive pass I realistically would not have completed manually. I could review the findings quickly, prioritize the blocking onboarding issue first, and decide which smaller UI problems were actually worth fixing.

Using personas to simulate real customer behavior
My husband, EJ Lawless, pushed this workflow beyond bug hunting. Instead of asking the browser agent to verify functionality, we asked it to behave like different types of customers and describe the experience from inside the workflow.
Giving the agent roles instead of checklists
I dictated the prompt with Monologue and intentionally kept it fairly open-ended. The assignment was to use ChatPRD from three perspectives: a product manager creating a PRD after a meeting, an engineer turning that PRD into a technical specification, and a team lead trying to understand how the broader team uses the product.
I want you to go through the core of ChatPRD's chat and document creation mode as three different personas.
1. One as a product manager trying to quickly create a PRD for a feature that they just got out of a meeting about.
2. The second, I want you to impersonate an engineer who is taking that already created PRD and trying to make a technical spec out of it...
3. And the third, as a team leader, try to figure out how your team is using ChatPRD.
...I want you to create a doc providing research style critique about the overall experience, including friction points, places of delight, and improvements you think we can make to serve those three personas better. See Conduct AI-Powered User Research by Impersonating Personas.

The friction points that appeared in context
While acting as the engineer persona, the agent attempted to reference the document created earlier by the product manager persona and ran into what it described as a "structural break." I already knew cross-thread document references had limitations, but seeing the problem emerge naturally inside a realistic workflow made the weakness feel much more consequential.
The personas also exposed a confusing loading state after an error where the system felt stalled without enough feedback about what was happening. That is the advantage of role-based testing over scripted QA. The agent is not just checking whether buttons work. It is trying to accomplish a goal inside a believable context, then explaining where momentum breaks down or confidence disappears for the user.
Delegating the first pass on LinkedIn messages
LinkedIn inboxes are a perfect example of low-value navigation work. The messages matter. The repetitive sorting does not. Browser automation lets me offload the triage process without needing an API integration or a custom workflow. You can follow the full implementation in Automate LinkedIn Inbox Triage with AI Browser Automation. See Automate LinkedIn Inbox Triage with AI Browser Automation.
Giving lightweight reply rules
I open LinkedIn in the browser and give Codex a simple policy: respond to straightforward thank-you notes, surface anything important for ChatPRD or the podcast, and leave guidance for messages that need a more thoughtful reply from me.
Please use browser to go through my recent unread messages and reply to any that are super critical for ChatPRD or the podcast. Leave me notes here on the others about how I should reply. If this is just a friendly thank you note reply in a friendly way.

Choosing a model that matches the work
The agent works through unread messages, handles low-risk responses, and flags conversations that require context or nuance. I still review anything sensitive or strategically important, but I no longer spend time sorting through every thread just to discover which ones matter.
I first ran this workflow using GPT-5.6 Soul on high effort settings, which turned out to be overkill for inbox cleanup. Switching to Tara at medium effort made the workflow faster and less expensive without noticeably hurting the quality of the triage. That tradeoff matters. Browser automation already adds execution overhead, so matching the model to the actual judgment required keeps these workflows practical.
Letting Codex shop a sale for me
Before a trip to Hawaii, I needed clothes and had no interest in manually digging through sale pages. Free People was running a promotion, so I handed the browsing process to Codex instead.
Using constraints to shape the shopping results
I used @Chrome and gave the agent a surprisingly human set of constraints: medium sizing, Hawaii weather, comfort, breastfeeding-friendly clothing, and a goal of ending with ten candidate items in the cart. The prompt worked because it described the outcome and context clearly without micromanaging every search step.
@Chrome I'm going to Hawaii this weekend and I need new clothes, good news, exclamation mark. Free people has 25% off their sale. I would love for you to go through using Chrome browser use and pick out 10 items in my size, you can pick size, medium. That would be great for Hawaii. Remember, I'm a breastfeeding mom. I just had a baby six months ago. So pick things that are comfortable, that are breastfeeding friendly, and that would be great for the weather in Hawaii in late July. what I want you to do is end up with 10 things in my cart that I can pick from and buy. Thanks.

One human interruption in an otherwise autonomous run
The live browser view let me monitor progress while the agent searched sale inventory, filtered by size, evaluated styles, and added options to the cart. The run eventually paused at a CAPTCHA, which required me to complete the human verification before returning control.
That handoff actually felt like the correct division of labor. The agent handled the long and boring part: browsing dozens of listings, checking fit constraints, and narrowing options down. I handled the one step specifically designed to require a real person. The final cart included loose pants, maxi dresses, and button-down tops that matched the trip constraints surprisingly well.
Smaller browser tasks that add up quickly
Once I started using browser and computer use regularly, the same pattern kept showing up in smaller operational chores that involve lots of navigation but relatively little judgment:
- Forms: Complete camp registrations, procurement forms, and other repetitive web forms.
- Phone and device tasks: With iPhone Mirroring, I used Codex to operate my router app from a hotel, open the firewall ports I needed for SSH access to my Mac minis, and close them again afterward.
- Documents and spreadsheets: If a direct integration fails, I ask the agent to open the relevant web app and complete the work in the browser.
Browser and computer use have become some of the most useful tools in my daily workflow because they absorb the mechanical overhead of digital work. The agent can click through repetitive interfaces for long stretches without getting bored, while I stay focused on approvals, priorities, and decisions that actually benefit from human context.
The workflows worth copying are the ones with visible outcomes and easy review afterward: QA passes, inbox cleanup, research simulations, shopping filters, repetitive forms, and operational maintenance. Browser agents are excellent at persistence and navigation. They are still weak at ambiguity, high-stakes judgment, and anything where the wrong click carries real consequences. The practical setup is not full autonomy. It is supervised delegation with clear boundaries about when the agent should stop, ask, or hand work back.
Watch or listen
Sponsors
Thanks for supporting How I AI
Deploy fleets of agents that handle real work
The creative AI platform for images, video and more
Build your next product with ChatPRD
Turn an idea into a PRD, user stories, and a plan.


