On a Monday morning I wanted to see the week's calendar next to the inquiry emails from a client site. Cowork could turn that into a table in minutes, and still my hands stopped. There were several ways to let it read either one.
I could connect a connector. I could let Claude in Chrome work through the screen. Or I could export just what I needed and drop it in a folder. All three end in a similar table. What differs is how much I've allowed Claude to touch along the way.
Here is how I now rank the three, not by speed but by reach, plus the prompt I hand over once I've picked one.
The day I clicked "Next" without reading
I'll be honest about how this started. The first time I connected a connector, I clicked through the permission screen. I was too pleased that it worked.
A few days later I opened the list of connected services and, for the first time, actually read what I'd allowed. The task only needed reading, but write access had come along with it. Nothing bad happened. Still, my stomach dropped a little.
A read-only job doesn't need the power to write. So I changed the order in which I choose a route.
The three routes in one table
Same goal in every row: let Cowork read my calendar and inbox. This is my own working summary, and screen names or behavior can change between versions, so please check what you see on your side.
| Route | What Claude can reach | Effort | Good for |
|---|---|---|---|
| File export (CSV or PDF into a folder) | Only the folder you hand over | You export by hand | One-off summaries, services you'd rather not connect |
| Connector | Whatever the service's permissions allow (read-only or read-and-write) | One setup | The same read, repeated every week |
| Claude in Chrome | Anything you can do while logged in on that screen | No setup, but fragile when a page changes | Services with no connector |
Speed and narrowness don't line up. The connector looks easiest but can be wider than you expect, depending on what you approved. Claude in Chrome needs no setup, but it acts with your authority. A logged-in screen is also where the send button and the delete button live.
My rule: for reading, start narrow
After trying all three, I settled on one line.
Reading jobs get the narrowest route that works. I widen only when the narrow one falls short.
In practice it goes like this:
- First, ask whether I can export only what's needed into a folder. For email, that's subject lines and short excerpts. For the calendar, this week's list. Most of the time that's enough.
- Once the same read repeats weekly, move to a connector. Open the permission list first and check that it can be limited to reading. If it can't, I skip that connector.
- Only for services with no connector and no export, use Claude in Chrome, and name the screen it may look at up front.
I treat the third route carefully because one wrong click on a screen costs more than a wrong read from a folder.
The prompt I hand to Cowork
After picking a route, I draw the line again in the prompt. Even with permissions set, saying "read only" in the request itself kept Cowork steadier whenever it was unsure.
Task for today: sort last week's inquiry emails by type and summarize them in a table.
Allowed source: only the CSV files in the folder "inquiry-test"
Scope: read, summarize, and save the result as a new file
Do not: send, reply, delete, overwrite existing files, or post anything to an outside service
If unsure: before doing anything, ask me in one sentence what you intend to do
Output: three columns (type, count, one representative sentence); save under a new file name with today's dateThree habits sit behind it: name the allowed source, write the "do not" list first, and tell it to stop and ask when unsure.
Writing a "do not" list felt a little distrustful at first. But being blunt there lets me hand the work over with a lighter heart.
Where I never use the Chrome route
There are a few places where I keep Claude in Chrome out entirely: anything that holds money, anything that sends messages to other people, and anything where one mistaken click can't be undone. In those places the screen is not a reading surface for me. It's a set of buttons.
For these, I export what I need and read the file myself first, or I let Cowork read the export. It's slower by a few minutes. But when I picture the worst version of a wrong click, those few minutes look cheap.
I may be too careful. Still, I'd rather loosen a rule later, once I've watched how Cowork behaves, than tighten it after something has already gone out.
A first week, if you're new to this
If you're starting out, I'd try this order.
- Day one: make a dummy CSV with three rows, put it in a folder, and run the template above.
- Day two: export just this week from your calendar and have it read that with the same template.
- Day three onward: only if a read keeps repeating, move it to a connector, and open the permission list before you do.
Moving to a connector can wait until exporting by hand truly wears on you. If you hurry, you may end up clicking "Next" like I did.
Three checks when the result looks off
When a read doesn't come out as expected, I check these in order.
- Is the range right? The folder location, the exported period, or the wrong account connected.
- Is the permission too little, or too much? Too little means it can't read; too much plants the seed of a different problem.
- Does the prompt say "ask if unsure"? Without it, Claude may fill gaps by guessing.
If all three look fine and it still fails, I step back to the file export before widening anything. Widening can wait until I know the cause.
One thing to do next
Open the permission list of one connector you already use, just once. If a read-only job has write access attached, trim that one connector first.
For me it comes down to this: a reading job gets a reading route. I try to keep to it even on hurried mornings.