How to Use Claude Cowork: Your First Task, Task Briefs, and Permission Modes

You open the message box, select Cowork instead of Chat, point it at a folder, and describe what finished looks like. That is the entire interface. The hard part is the last step, because describing a job well enough that something else can complete it without three follow-up questions is a management skill, not a software skill.

Which is why the people who get good at this fastest are not the technical ones. They are the ones who have handed work to another person before and watched it come back wrong.

If you have never given an agent a folder, the thing to understand first is that background agents work differently from chat: the work continues after you close your laptop, and sessions and files save to your Claude account so they follow you between devices. You are not steering a conversation. You are assigning a job.

How do you start a task in Claude Cowork?

Four steps. Find the message box, select Cowork instead of Chat, give it access to the folder you want worked on, and describe the outcome you want. Select Chat to go back to a normal conversation.

That is genuinely all of it. Every other guide will stretch this into a thousand words of screenshots, and none of that helps you, because nobody gets stuck here. People get stuck on the fourth step, which is the only one that requires judgment.

Two things worth knowing before your first run. Cowork requires a paid plan, and it uses more of your usage than chatting does, because multi-step work is compute-intensive. Your usage across web, desktop, mobile, and Claude Code draws from one shared pool, so a heavy Cowork session leaves less room elsewhere that day. If you want the full breakdown of which plans and platforms have access, that is covered separately.

What should your first task actually be?

Pick something real enough that a good result saves you an hour, small enough that you can review the whole output in five minutes, on a folder you copied first. Those three constraints together are the entire answer, and almost nobody meets all three on their first attempt.

Real enough matters because a toy task teaches you nothing. If you ask it to rename three files, it renames three files, and you learn only that renaming works.

Reviewable in five minutes matters because the first task's real job is calibration. You are not trying to get work done. You are trying to find out how this thing interprets your instructions, and you can only learn that by reading everything it produced.

Copied folder matters because you are going to write a bad brief the first time. Everyone does. On a copy, a bad brief costs you nothing.

Three that work well:

Sort and rename a folder that has gone feral. Downloads, a client folder, a shared drive nobody has touched in a year. You supply the naming convention and the category structure. It is real work, the output is easy to scan, and you find out immediately whether your instructions were specific enough, because a wrong naming convention is visible at a glance.

Turn a pile of notes into one document. Meeting notes, call transcripts, scattered voice memo transcriptions. Ask for a single summary with a section per project and open questions listed at the end. This tests something harder than file handling: whether it can hold context across many files and produce one coherent thing rather than a concatenation.

Reformat a batch of files against a template you supply. Old proposals into your current format, inconsistent spreadsheets into one schema, past reports into the layout you use now. You give it the template. The finished state is unambiguous, which makes it an unusually good teaching task.

The two failure modes are opposite and both end with people deciding the tool does not work.

Too trivial proves nothing. It succeeds, you shrug, you go back to chat.

Too large is the more expensive mistake. Someone points it at four years of business files and asks it to organize everything. It runs, it produces an enormous amount of work, and there is no way to check any of it. When one thing looks wrong, the whole result becomes untrustworthy, because you cannot tell whether you found the only error or the first of two hundred.

How do you describe a task so it gets done right?

Describe the finished state, not the steps. Most people write instructions the way they would give directions, one action at a time, and that is exactly the format that produces a mess, because any step you forgot becomes a gap the agent fills with a guess.

Four things separate a brief that works from a request that does not.

Describe what done looks like. "Every file in this folder is named by client, then date, then document type, and sits in a subfolder for its client" is a finished state. "Go through the files and rename them" is a wish. The first can be checked. The second cannot even be evaluated.

Name what not to touch. This is the line people skip and regret. If there is an archive folder, a file with a version you need preserved, or anything you have not backed up, say so explicitly. Silence is not protection.

Say where the output goes. New folder, existing folder, single file, one file per source. When you do not specify, you get a reasonable choice that is not yours, and then you spend twenty minutes moving things.

Say what to do at ambiguity. The single highest-leverage sentence in any brief: if something is unclear, stop and ask rather than guessing. Without it, an agent resolves ambiguity on its own and keeps going, and you find out about the decision after it has been applied two hundred times.

Task brief template

Goal: what finished looks like, stated as an end state rather than a list of actions.

Source: the exact folder to work in.

Output: where finished work goes, in what format, and whether originals stay untouched.

Leave alone: folders and files not to modify, move, or rename under any circumstance.

Done means: how I will verify this is correct when I review it.

At ambiguity: stop and ask me before guessing. Do not resolve unclear cases on your own.

Worked example:

Goal: every proposal in this folder matches the format of the template file, with client name and date in the header and the pricing table at the end.

Source: the copied-proposals folder.

Output: reformatted files into a new folder called proposals-updated. Original files stay untouched.

Leave alone: anything in the archive subfolder.

Done means: I can open any three files at random and they are laid out identically to the template.

At ambiguity: if a proposal is missing a pricing table, do not invent one. List that file and keep going.

Notice that the example is longer than the request most people would type. That is the trade. Ninety seconds of writing replaces the twenty minutes you would otherwise spend correcting the output, and unlike the correction, the brief is reusable.

If you find yourself writing briefs this precise for repeatable technical work, that is the point where the difference between Cowork and Claude Code starts to matter, and it is worth knowing which one your work belongs in.

Which permission mode should you use?

There are three: Manual, Auto, and Skip. Use Manual while you are learning, Auto once you trust a category of work, and Skip almost never.

Manual shows you each action before it happens. It is slower and it is the correct default for your first tasks, because it is the only mode that teaches you how your instructions translate into actions. When you see it about to move a file you did not expect it to touch, you have learned more about brief-writing than any guide can teach you.

Auto approves actions as it goes and reviews each one for safety, including checks for data exfiltration and prompt injection. That review is real work, which is why Auto consumes more usage. It also has hard limits: Auto will not approve granting access to additional folders, deleting files, or creating scheduled tasks. Those still come back to you. Move to Auto per category of work, not globally. Reformatting documents in a folder you copied is a good Auto candidate. Anything touching originals is not.

Skip removes the review step. There are narrow cases for it, on throwaway copies where nothing is at stake, but if you are reaching for Skip because approvals are slowing you down, the actual problem is that your task is too broad. Tighten the brief instead.

Independent of mode, permanently deleting files requires your explicit permission. That is a floor, not something you configure.

How do you use Claude Cowork on Windows?

The same way you use it on macOS. Cowork runs inside Claude Desktop on both, and the task flow is identical: select Cowork in the message box, grant folder access, write the brief, approve actions.

What differs between platforms is the desktop app, not Cowork. Installation and file paths look different on Windows than on a Mac in the way they always have. None of that changes how you brief a task or which permission mode you pick. If a guide promises a separate Windows method, there is not one.

How do you use Claude Cowork safely?

Copy the folder, scope narrow before you scope wide, and never point it at documents you did not write.

That third rule is the one people underestimate. An agent that reads a document can act on instructions inside that document. A PDF someone emailed you, a spreadsheet from a vendor, a file downloaded from a source you do not control: all of these are text an agent will read, and text can contain directions. Auto mode reviews for exactly this kind of prompt injection, but the cheaper defense is not putting untrusted documents in the working folder in the first place.

The rest is unglamorous discipline. Work on copies until you have run a task type enough times to predict the output. Keep the first tasks inside one folder rather than pointing at a whole drive. Read the output completely, every time, until you stop finding surprises. Deletion always requires your explicit approval, so the risk is rarely destruction. It is quiet, plausible-looking wrongness applied at scale, and the only defense against that is reviewing while the scale is still small.

What does using it well look like after the first week?

You stop retyping the same instructions and start writing them down once. That transition is the whole game, and it usually shows up around task five or six.

The pattern is easy to spot. The same three sentences appear in every brief. The same folders come up. You make the same correction you made on Tuesday. Every one of those is a rule you are re-teaching from scratch on each run, and re-teaching is the tax you pay for the agent starting cold every time.

The fix is to put the standing context in a file the agent reads instead of in a message you retype. Your naming conventions, your formats, the folders that are permanently off-limits, the way your business names things. That is what a CLAUDE.md file does as a business operating system, and it is the difference between a tool that is impressive once and one that gets more useful every week.

It is also the reason my presentations changed. The model was the same model everyone else has. What changed was that it was working from my resources instead of from a generic starting point, and generic input is what makes generic output.

Once that clicks, the ceiling on what you can hand off stops being technical skill and starts being how clearly you can describe work. That is a much better ceiling to have, and it is the same one that makes Claude Code usable by non-developers.

If you want to see how the whole system fits together, from first task to standing rules to running real operational work without touching a terminal, the free masterclass walks through it.