Let's consider a five-person firm. Maybe a consulting firm (as was the build by @Eytan Levy ). Each consultant has a workspace of markdown files, client context, working notes, output logs, and Claude Code runs on top of it. The whole thing lives in one company repo. Everyone clones it, pulls in the morning, pushes at the end of the day. It works. I'd build it the same way. Now ask what's stopping consultant three from opening client seven's folder. The honest answer is nothing. She just doesn't. There's a contract, there's training, she's a professional, and you know her. That's a real control and I'm not going to pretend otherwise. But it's worth being precise about what's actually holding the system together, because it isn't the architecture. Git permissions stop at the repo boundary. Inside the repo, everything is readable by everyone who cloned it. The thing keeping client seven private is not a permission. It's a person. That costs you nothing while it's true. The problem is that nothing in the system tells you the day it stops being true. And it stops for ordinary reasons. You hire past the point where you personally know everyone. You bring a contractor in for one engagement. Someone leaves for a competitor. You sign a client whose contract says their data can't sit on personal devices. You take on a client who competes with a client you already have, and the gap between two folders suddenly needs to be an actual wall. On the day one of those lands, you reach for the lever and find out what you really have. You remove the person from the repo. That stops their next pull. The clone they made three weeks ago is on their laptop, complete, and it stays there. Repo permissions govern who can get it. They don't govern who has it. That is distribution control, and most people think they bought access control. The part I keep my eye on is calling this a big-company problem. It isn't a headcount thing. A fifty-person firm of salaried employees under proper contracts might be perfectly fine. A three-person shop with one contractor who also works for your competitor is not. The trigger isn't scale. It's the first time there's someone inside the system you wouldn't personally vouch for. That usually shows up with growth. It doesn't have to.

If your main files still sit under ~/.claude or ~/.codex, you're still not quite there yet, or more importantly, safe. Think: if the Claude app decided to nuke itself tomorrow, wiped the whole application folder and everything inside it, how cooked are you? With what Grok AI pulled off recently (downloading whole Repos of information without permission), you can never be too safe. <- PLEASE read up on this if you're not caught up. Now, however ridiculous the idea you might think, the proposition still stands. If your instructions, context routing, and memory all live inside ~/.claude (or wherever your app stores its files), you don't have a model-agnostic structure. You have an app-dependent one. If Claude suddenly decides to stop supporting certain file customizability and directly, it'll be an immense and frustrating headache to fix. While it likely won't happen soon, or at all tbh, the simple fix is decoupling. My whole global system, I personally named it "BABEL," lives in its own folder directly, version-controlled, completely separate from any app folder. What sits inside the Claude and Codex apps is just a thin layer of symlinks and shims pointing back to my global ICM structure. If my Claude wiped its own folder right now: - My instructions, memory, registries, skills, docs are completely fine. - Restoring is one simple prompt for me. Re-point the symlinks, and I'm good. - Want to move to a different client entirely? Same source files, new shim layer. The brain doesn't move at all, and even a fresh, completely new LLM harness is good enough to wire itself in with symlinks. Was inspired to post this after the recent Grok incident; happy to break down how the symlink layer works if anyone wants it.