If you've been feeling like this tool keeps telling you no, read this before you conclude anything about how good it is.

That was my first few months. I would ask for something reasonable, get told it could not be done, accept it, and move on a little more frustrated each time. After enough of those I had quietly built a mental list of things Claude "could not do," and I stopped asking. The list was wrong. Almost every item on it was something one of Claude's tools could do, or could build a way to do, and I had simply asked the wrong one and taken its answer as final.

Why don't Cowork and Claude Code share the same skills, connectors, and settings?

Your setup does not live in three places, one per product. It lives in two.

Your Claude account. Skills and connectors you turn on in your account settings are shared by Cowork and by claude.ai chat. Turn something on once and both have it, on any computer you sign into.

Your computer. Claude Code keeps its own skills folder, its own connectors, its own memory, and its own scheduled tasks, all sitting on the machine in front of you. None of it reaches your account, and none of it reaches your other laptop.

Cowork and chat feel connected because they draw from the same bucket. Claude Code feels disconnected because it has a bucket of its own. Once you can see the two buckets, the confusion about vanished skills and settings that don't carry over mostly stops.

What's the real difference between Cowork and Claude Code?

The question isn't which product to open. It's whether the job needs to run on your computer. Drafting, filing, research, and briefing do not. Installing something, running it, using git, or building a connector that does not exist yet all do.

Cowork carries the keys that already exist. It arrives with a big ring of them, one for each service someone has already connected it to. Most days one of them fits and you are through the door in seconds.

Claude Code is more like a tech handyman. Here is the belief worth dropping first, because it is the thing actually standing between most people and this half of the tools: Claude Code is not for building apps. That is what everyone assumes, and it is why they never open it. A handyman does not build houses. He builds the one shelf that fits the weird alcove nobody makes a shelf for, and afterward you use that shelf every single day and forget it was ever custom.

I did not go to Claude Code to become a software developer. I went because I needed several email accounts connected at once, which is about as ordinary a chore as exists. It is closer to hanging a shelf than to building a house.

The rule: a no from Cowork means none of its keys fit this lock. It does not mean the thing is impossible, and it does not mean you need to hire a developer. It means you have reached the edge of what came prebuilt, and the next step is asking the handyman to build the door.

What do I do when Cowork tells me it can't do something?

Don't treat that as the end of the conversation. Take the exact same request to Claude Code and ask.

It often won't say yes either. It will say something better: no, but would you like me to build a way to do it. Say yes. That third step is the one nobody warns you about, and it is the entire reason Claude Code matters to someone who does not write software. You are not going there to get one task done. You are going there to get a capability built, which you then use forever afterward, usually from Cowork.

Do I need to know how to use a terminal to use Claude Code?

No, and this is the other thing nobody tells you. When Claude Code says "open a terminal and run this command," that is not an instruction you are obligated to follow. It is a description of what needs to happen. You are allowed to answer: can you just do that for you.

And it will, almost every time. It runs the command itself and shows you the result. Sometimes you see the output appear directly, sometimes you barely see anything at all and simply get told what happened. Either way there is no window for you to manage, nothing to type into, and nothing to close.

Better still, it reads the output. When something fails it notices, works out why, and fixes it, a genuinely different outcome from pasting a command yourself and staring at an error message you have no way to interpret.

There is a short, deliberately narrow list of things it cannot do for you, and every item on it is something that is yours to authorize: signing in to an account, anything asking for your computer's admin password, approving a permission prompt, and decisions with real consequences like sending, publishing, spending, or deleting. Everything outside that list is fair game to hand off.

Why did my Claude skill stop working with no warning?

The most common cause is a formatting problem, not a real failure. A skill has to be a folder containing a file named SKILL.md. A single flat .md file sitting loose in the skills folder is ignored completely, no error, no warning. It simply stops appearing, and nothing tells you why.

Watch out: if a skill that used to work has quietly vanished, check the file format before assuming anything else is broken. This failure is invisible by design, so it only ever gets caught by someone going and looking.

Is it safe to keep a code project inside a Google Drive folder?

Keep git repositories out of Drive-synced folders. The advice usually given is about clutter, and that is the minor problem. The real one is corruption. Git repeatedly rewrites a small set of internal files and assumes nothing else is touching them mid-write. Drive's background sync can collide with exactly those writes and corrupt the repository, sometimes silently losing work.

Code that runs belongs in a git repository, backed up to GitHub, not inside your Drive-synced documents folder. If you already have code sitting in Drive, the safe move isn't to panic and move everything at once, it's making sure the project is actually pushed to GitHub, so a real copy exists that isn't depending on Drive to stay intact.

What's the safest way to run something on a schedule with Claude?

There is more than one option, and picking the wrong one is a common, avoidable mistake. It splits on two questions: does the job need Claude's judgment, or just a script, and does your computer have to be awake for it.

Whatever you choose, build the failure alert at the same time you build the automation, not later. A job that fails silently is worse than no automation at all, because you go on trusting a result you are no longer actually getting.

What should I actually do differently starting today?

Stop accepting no as the end of the conversation. The next time Cowork tells you it cannot do something, do not close the tab and file it away as one more thing Claude cannot do. Take that exact request to Claude Code and ask. You will often get back something better than yes: no, but would you like me to build a way to do it.

Say yes. That is your handyman offering to build the door, and the door stays built.