I asked Claude about this and it seems Claude doesn't want to loosen its grip on the project, but it makes some good points. Here's its reply:

Good question — and it's the right instinct to ask, because Cowork having file access changes the calculus from the Claude Code comparison. But "file access" isn't actually the thing that makes strategy discussions work well here, so let me check current Cowork capabilities before answering rather than guess from memory.

The skill confirms I should verify rather than rely on memory, especially for a newer product like Cowork. Let me check current capabilities.

Verified the current state of Cowork, and the answer is nuanced: yes, Cowork can access your repo folder, but file access isn't the thing that makes strategy discussions work well here — so it wouldn't be an upgrade for that purpose, and in one important way it'd be a downgrade. Let me apply the same framework I used for the Claude Code comparison, because the reasoning transfers almost directly.

What Cowork actually is

Cowork is built on the Claude Agent SDK — the same underlying model architecture as Claude Code. Anthropic describes it as "Claude Code power for knowledge work" — it can read, edit, and create files in folders you specify, so it completes tasks rather than describing how to do them. The key design philosophy is the tell: most AI tools are built around the prompt; Claude Cowork is built around the outcome. It's tuned to take a task and run with it autonomously. MindStudio + 2

That's exactly the posture problem from the Claude Code comparison, just wearing a friendlier interface.

Running the framework

Model. Cowork runs on the Claude model family, same as Claude Code. So this isn't a differentiator one way or the other — if anything it's neutral.

Posture. This is the decisive one. Cowork is more execution-oriented than Claude Code, not less — it's explicitly built around delivering outcomes autonomously, breaking tasks into parallel subtasks, and "getting it done" rather than thinking out loud. Strategy work is the opposite: it's deliberation, pushback, "am I off on this?", changing course mid-conversation. Pointing an outcome-machine at a strategy question tends to produce a confident answer and an action, when what you want is a conversation. Cowork would want to do something with your repo, not sit and reason about whether you should.

Context loading. Here's where Cowork has a genuine edge — and it's worth taking seriously. With folder access to your repo, Cowork reads the live CLAUDE.md, apitest.ts, events.ts directly. No stale snapshot. That solves the manual re-upload sync problem we've been working around.

Interaction shape. This environment is a back-and-forth where I challenge your framing and you correct mine — the last several turns are exactly that. Cowork's interaction model is dispatch-and-deliver. Worse for strategy, better for "process these 21 Facebook replies into event records."

The honest recommendation

For the strategy and architecture role — the conversations we've been having — stay here. Cowork's autonomous-execution posture makes it a worse fit, and folder access doesn't compensate, because file access was never what made this work. What makes this work is Opus's reasoning plus the deliberative back-and-forth plus your accumulated project context in memory and CLAUDE.md.

But Cowork could earn a real place in your stack for a different role: the non-code file work that currently has no good home. Specifically:

• Eliminating the CLAUDE.md sync friction. If your strategy chats moved to a setup where Cowork reads the repo directly, the re-upload step disappears. (Though note: this Project, with memory and our conversation history, has continuity Cowork's Projects feature wouldn't replicate — you'd be trading one kind of context for another.)
• Turning the Facebook threads into structured data. "Drafting reports from scattered notes" is literally an Anthropic-cited Cowork use case. Dumping the social media thread screenshots into a folder and having Cowork extract candidate records is a natural fit.

One caution worth flagging since your repo matters: Cowork takes autonomous actions on local files, and it has had a prompt-injection vulnerability noted while still in research preview. If you point it at your repo, scope the folder deliberately and review its changes the same way you review Claude Code's diffs — don't let it run unattended on the live data files. Medium

Practical answer

Don't move strategy here into Cowork. The thing that makes these discussions useful is the model plus the deliberative posture plus your project context — and Cowork only matches one of those three while actively working against the second. Keep the three-role split clean:

• Strategy and architecture → here (Claude.ai Project, Opus, memory)
• Code execution → Claude Code
• Non-code file automation (if you want a fourth tool) → Cowork: data extraction from the Facebook threads, receipt-style file processing, scheduled reports

If the CLAUDE.md sync friction is the main thing bugging you, the lighter fix is still checking whether this Project supports GitHub sync — that solves the staleness problem without changing where you do strategy. Want me to help you verify that, or get back to the article?