Love your content on AI team! I'm Sia from Novita AI—we help developers access and deploy LLMs instantly, without the hassle of managing infrastructure themselves.
We're currently building our creator network through an affiliate program. Your followers are exactly the kind of developers and builders who benefit from our service, and I think this could be a valuable opportunity for you.
Federico great question I also wanted to chime in here. I'm a strong proponent of keeping a company's file system and AI systems separate. There's tons of tweets recently about Anthropic accidentally flagging corporate accounts and shutting off Claude access to entire organizations...losing shared context and memories etc. By keeping them separate, if a company decides to move from one AI system (Claude) to another (Cursor), then all they have to do is point the new AI system to their knowledge base and minimize disruption without migration.
I can't get into the details but our teams learned this the hard way recently and are now making sure we limit dependencies on one AI vendor.
Great points here! I've tried following the steps, but it seems that even though I make the workspace folder (containing shortcut folder) available offline it still tells me it can't retrieve those files because of the symlink issue. What am I doing wrong?
This is the error:
When you select the workspace in Cowork, I can only see files inside that selected folder. But the "Megabrain" inside of the workspace folder is itself a symlink pointing to a path outside the workspace folder (specifically /Users/XXX/Library/CloudStorage/GoogleDrive-.../...). My sandbox refuses to follow symlinks that escape the mounted workspace, so even if the files are downloaded locally, I can't reach them through that link.
What!! No way! Thanks for following up. I tried again today and hit the same wall. So you're saying you just put the shared folder shortcut in the workspace folder and worked from there no problem without having to point at both the workspace folder and sub shared folder at same time from Claude Cowork?
Oh! Wait... ok it can locally see inside the symlink to know what files are there, and it claims it can read if it's txt or md, but not if it's binary docs like docx or xlsx.
I asked Claude why, but it's beyond my expertise to verify its explanation. It did say for the binary files it was using Google Drive MCP
So the good news is 1) it can list what's inside the symlinked directory and 2) can access local text-based file formats, and 3) can access binary files via the Google Drive MCP
Interesting, I tested it now in the same Claude Desktop app - claude code in one thread, claude cowork in another thread.
Claude code worked fine and just asked me for approval (same with Cursor), and claude cowork had trouble. (again, same exact desktop application, so interesting). It seems even though both are Claude Agent SDK at their core, they implemented them differently in terms of how they run on our computers.
The easy short term solution is to stick to the Claude Code tab inside the Claude Desktop app. Medium term, I wonder if the other cloud sync options can do this without "shortcuts" (e.g. dropbox shared folders). Or using Shared Drives instead of Shared Folders, with that tradeoff.
If it's any consolation, none of the blockers here are AI-related. It's plumbing quirks of Google Drive coinciding with how Anthropic is implementing co-work at the moment. Can't wait for all of these hacks to be obsolete.
Agreed, can't wait! I figured out a short term fix, pointing directly to the shortcut folder gives cowork the "access" it needs. For some reason pointing at the workspace folder wasn't enough. Defeats the purpose of having the megabrain in the workspace folder now though. I guess I just have to point cowork at the shortcut and then also at my working folder every time I'm going to do work?
Great piece. One question though, why not Claude Teams Projects for the shared context problem? You can create shared projects with custom instructions, upload reference docs, and give the whole team access to the same context. No symlinks, no Google Drive desktop installs, no "make available offline." It's not a local filesystem agent, but for the 80% of knowledge workers who aren't going to learn terminal commands, it seems like the simpler answer. Curious what you think is missing from it.
Hey Federico, great question. Claude Teams projects could also give a lot of the value, for sure. For a lot of teams it could be a very wise compromise, or starting point. None of the companies I've worked with chose that option (some were using Claude Projects and wanted to move off of it) so I don't have as much depth on it.
The best way to use AI at work today is working with a full-fledged file system (local or virtual), for many reasons: far faster learning loop, persistence, customizability, and individuals being able to keep their own private area for collaborating with AI.
That said, I'd trade all of that for adoption and having people truly see their work differently, which is most important. Long term, I hope the jankiness of a local filesystem goes away quickly so it becomes an easy choice.
(Btw, to use Claude Desktop doesn't require any terminal commands, they've done a great job with Cowork and even Claude Code as a GUI desktop app.)
Great points. We’re currently running a team experiment at my company, and we chose GitHub as our knowledge base. I like the “driving stick” analogy - that’s exactly how it feels for a PM who doesn’t code much.
However, since we have some highly technical people involved, we’ve moved beyond simply sharing knowledge or producing “knowledge artifacts.” We’re actually building things together (skills, MCPs, connectors, etc.), and GitHub has been very helpful at this stage.
Hi,
Love your content on AI team! I'm Sia from Novita AI—we help developers access and deploy LLMs instantly, without the hassle of managing infrastructure themselves.
We're currently building our creator network through an affiliate program. Your followers are exactly the kind of developers and builders who benefit from our service, and I think this could be a valuable opportunity for you.
Happy to share details if you're interested.
Best,
Sia
Federico great question I also wanted to chime in here. I'm a strong proponent of keeping a company's file system and AI systems separate. There's tons of tweets recently about Anthropic accidentally flagging corporate accounts and shutting off Claude access to entire organizations...losing shared context and memories etc. By keeping them separate, if a company decides to move from one AI system (Claude) to another (Cursor), then all they have to do is point the new AI system to their knowledge base and minimize disruption without migration.
I can't get into the details but our teams learned this the hard way recently and are now making sure we limit dependencies on one AI vendor.
Nice one, thanks as usual, Tal.
Great points here! I've tried following the steps, but it seems that even though I make the workspace folder (containing shortcut folder) available offline it still tells me it can't retrieve those files because of the symlink issue. What am I doing wrong?
This is the error:
When you select the workspace in Cowork, I can only see files inside that selected folder. But the "Megabrain" inside of the workspace folder is itself a symlink pointing to a path outside the workspace folder (specifically /Users/XXX/Library/CloudStorage/GoogleDrive-.../...). My sandbox refuses to follow symlinks that escape the mounted workspace, so even if the files are downloaded locally, I can't reach them through that link.
Hey Matias! I was just setting up a new workspace and the symlink worked for me inside of Claude Cowork! Woo!
There's been a few updates in the last couple days, so hopefully one of them fixed it
What!! No way! Thanks for following up. I tried again today and hit the same wall. So you're saying you just put the shared folder shortcut in the workspace folder and worked from there no problem without having to point at both the workspace folder and sub shared folder at same time from Claude Cowork?
Oh! Wait... ok it can locally see inside the symlink to know what files are there, and it claims it can read if it's txt or md, but not if it's binary docs like docx or xlsx.
I asked Claude why, but it's beyond my expertise to verify its explanation. It did say for the binary files it was using Google Drive MCP
So the good news is 1) it can list what's inside the symlinked directory and 2) can access local text-based file formats, and 3) can access binary files via the Google Drive MCP
Interesting, I tested it now in the same Claude Desktop app - claude code in one thread, claude cowork in another thread.
Claude code worked fine and just asked me for approval (same with Cursor), and claude cowork had trouble. (again, same exact desktop application, so interesting). It seems even though both are Claude Agent SDK at their core, they implemented them differently in terms of how they run on our computers.
The easy short term solution is to stick to the Claude Code tab inside the Claude Desktop app. Medium term, I wonder if the other cloud sync options can do this without "shortcuts" (e.g. dropbox shared folders). Or using Shared Drives instead of Shared Folders, with that tradeoff.
If it's any consolation, none of the blockers here are AI-related. It's plumbing quirks of Google Drive coinciding with how Anthropic is implementing co-work at the moment. Can't wait for all of these hacks to be obsolete.
Agreed, can't wait! I figured out a short term fix, pointing directly to the shortcut folder gives cowork the "access" it needs. For some reason pointing at the workspace folder wasn't enough. Defeats the purpose of having the megabrain in the workspace folder now though. I guess I just have to point cowork at the shortcut and then also at my working folder every time I'm going to do work?
This was also helpful context: https://www.calebhunter.dev/blog/claude-cowork-google-drive-streaming-setup but doesn't really talk about the megabrain context concept cross org.
interesting! i had mirroring enabled and still ran into the issue, but this gives hope
Great piece. One question though, why not Claude Teams Projects for the shared context problem? You can create shared projects with custom instructions, upload reference docs, and give the whole team access to the same context. No symlinks, no Google Drive desktop installs, no "make available offline." It's not a local filesystem agent, but for the 80% of knowledge workers who aren't going to learn terminal commands, it seems like the simpler answer. Curious what you think is missing from it.
Hey Federico, great question. Claude Teams projects could also give a lot of the value, for sure. For a lot of teams it could be a very wise compromise, or starting point. None of the companies I've worked with chose that option (some were using Claude Projects and wanted to move off of it) so I don't have as much depth on it.
The best way to use AI at work today is working with a full-fledged file system (local or virtual), for many reasons: far faster learning loop, persistence, customizability, and individuals being able to keep their own private area for collaborating with AI.
That said, I'd trade all of that for adoption and having people truly see their work differently, which is most important. Long term, I hope the jankiness of a local filesystem goes away quickly so it becomes an easy choice.
(Btw, to use Claude Desktop doesn't require any terminal commands, they've done a great job with Cowork and even Claude Code as a GUI desktop app.)
Great points. We’re currently running a team experiment at my company, and we chose GitHub as our knowledge base. I like the “driving stick” analogy - that’s exactly how it feels for a PM who doesn’t code much.
However, since we have some highly technical people involved, we’ve moved beyond simply sharing knowledge or producing “knowledge artifacts.” We’re actually building things together (skills, MCPs, connectors, etc.), and GitHub has been very helpful at this stage.