Claude's computer use capability lets the model interact with a computer the same way a human does: move the mouse, click buttons, type text, read what's on the screen. It's positioned as a way to automate any task a human can do on a computer, which sounds transformative.
The reality is more nuanced. Here's what I've actually used it for in production, what works reliably, and where the limits are.
My Specific Use Case: LinkedIn Data Ingestion
LinkedIn does not have a public API for reading your messages or connection requests. If you want to build tooling on top of your LinkedIn data, your options are: use their official data export (which is a manual process and not real-time), scrape the site (which violates their terms of service and is technically fragile), or use browser automation.
I built a Chrome extension that uses Claude's computer use capability to read my LinkedIn inbox. The extension opens LinkedIn in a controlled browser session, navigates to the messages and connections sections, reads the content visible on screen, and passes it to my agent pipeline for processing. The agent then updates my CRM based on what it reads.
This is one of the cleaner use cases for computer use: reading data from a site that doesn't offer an API, in a context where the user (me) controls the account, using automation that mimics what I'd do manually.
What Computer Use Is Actually Good At
Reading semi-structured data from web interfaces. LinkedIn messages, connection requests, and profile information are displayed in a consistent-enough layout that the model can reliably locate and extract what it needs. The model is good at finding elements by their visual appearance and contextual meaning, not by brittle CSS selectors.
Navigating multi-step UI flows. Clicking through a series of screens that require reading what's on each screen to decide the next step. The model handles conditional navigation well - "if there's a notification, click it; if not, go directly to the inbox."
Handling UI variation. LinkedIn periodically changes its layout. A traditional web scraper breaks when a CSS selector changes. Computer use handles layout changes much more gracefully because the model understands the visual and semantic structure, not just the DOM.
Short, well-defined tasks. Tasks with a clear start, a clear end, and a manageable number of steps. "Open LinkedIn, navigate to messages, read the five most recent conversations, extract the names and message content, return the result." This works reliably.
What Computer Use Is Not Good At
Long, multi-step workflows. The longer the task, the more opportunities for something to go wrong - an unexpected dialog, a loading state that takes longer than expected, a UI element that's slightly offscreen. Reliability degrades with task length. Keep tasks short and targeted.
High-stakes actions. Computer use can click the wrong button. Before using it to take any consequential action (sending a message, making a purchase, submitting a form), think carefully about what happens if it clicks the wrong thing. I use computer use for reading, not writing. Human review happens before anything is sent.
Fast-changing interfaces. Some sites change their UI aggressively enough that even the model's visual understanding struggles to keep up. If the site's layout changes every week, computer use will require regular prompt tuning.
Sites with aggressive bot detection. Some sites detect automation via timing analysis, browser fingerprinting, or behavior pattern analysis. LinkedIn tolerates normal-speed browsing; it doesn't tolerate rapid-fire clicks or unnatural navigation patterns. Build in realistic timing between actions.
Anything requiring pixel-perfect interaction. Drag-and-drop, canvas-based UIs, games, and complex graphic editors are poor fits. Computer use works best on standard web UI elements: buttons, links, text fields, and dropdown menus.
The Chrome Extension Architecture
My implementation uses a Chrome extension rather than a headless browser, for a specific reason: I'm logged into LinkedIn in my normal Chrome session. The extension can access my authenticated session without needing to handle login, session cookies, or multi-factor authentication.
The extension has two parts:
Content scripts run in the context of the LinkedIn page and can read the DOM. They extract the visible text content - messages, sender names, dates, connection notifications - and pass it to the background script.
The background script sends the extracted content to my local MCP server, which queues it for the agent pipeline. The agent then processes the data, matches it to CRM contacts, and updates notes accordingly.
This architecture keeps the computer use portion simple: the extension handles the DOM reading using normal browser APIs. Claude's computer use capability is used for navigating to the right pages and triggering the extraction at the right time, not for reading every piece of data character by character.
The combination of standard extension APIs for data extraction and computer use for navigation is more reliable than using computer use for everything.
Prompt Design for Computer Use
The prompt for a computer use task is different from a text generation prompt. You're telling the model how to operate a UI, so clarity and specificity matter even more.
A few patterns that improved reliability:
Describe what to do when things don't look right. If LinkedIn shows a dialog asking about cookies or notifications, the model needs to know to dismiss it before proceeding. Enumerate the common interruptions and tell the model how to handle each one.
Use landmarks, not pixel positions. "Click the Messages icon in the left navigation sidebar" is more reliable than "click at coordinates 180, 340." The model can find the Messages icon even if the layout shifts slightly; coordinates are fragile.
Specify the completion condition. Tell the model explicitly what "done" looks like. "The task is complete when you have extracted the content from all visible messages and returned a JSON object with the sender names and message text." Without this, the model may continue exploring the UI unnecessarily.
Break long tasks into checkpoints. Instead of one long prompt that does everything, use multiple shorter prompts in sequence, each with a specific deliverable. This gives you visibility into where failures occur and makes each step easier to reason about.
Where This Fits in a Broader Architecture
Computer use is one tool in an automation stack, not a replacement for the whole stack. The right mental model is: use computer use for the parts of a workflow where there's no API and no other option. Use APIs, webhooks, and standard integrations everywhere else.
In my case: LinkedIn has no API, so I use browser automation to get data out. Once I have the data, everything downstream uses standard database operations, file reads, and API calls. The computer use portion is the smallest and most isolated part of the pipeline.
This approach limits the blast radius of computer use's reliability limitations. If the browser automation step fails (LinkedIn changed something, the page didn't load), the rest of the pipeline is unaffected. The agent simply skips the LinkedIn step and continues with other work.