Disaster recovery is not a backup. It is removing the platform from the critical path.

I spent part of last week rebuilding a working environment on a second Windows machine. My Linux laptop had died, and I wanted another machine ready to go rather than discovering, at the worst possible moment, that my work depended on one laptop behaving itself.

I had learned that the hard way months ago so the working state was already in my own structured operating environment. Files were version controlled, decisions were recorded, and the increasingly large collection of things I had built with AI was somewhere independent of the AI that helped build it. Then last week the problem changed.

I installed Claude Desktop on a second windows machine, signed into my Claude account and opened Cowork. Same conversations, same interface, it looked, to all intents and purposes, like the same desktop application I was using on WIN 1.

Except it wasn’t behaving the same way. Cowork on the freshly installed machine was running in the cloud, which in and of itself wasn’t the problem. The problem was that I had opened it on the desktop app, fully expecting it to not have local access to the Cowork folder as there was no Cowork folder yet. What I did not anticipate was that the Cowork instance I had running along with Code on the WIN 1 machine wasn’t running locally either.

Same shared thread, same almost-synced content, but no access to the local folders I expected. I didn’t know how or why this had changed, and I hadn’t used Cowork in a while, so me, being me, went looking.

There were a number of threads talking about it and the general consensus was people were far from chuffed, I knew how they felt, I was joining them.

However, it didn’t stop there. Code refused to start locally at all until I installed Git for Windows, another dependency not mentioned on the main Claude Desktop installation page. Anthropic documents it separately in the Claude Code Windows setup, but you only discover the distinction once the supposedly self-contained desktop app refuses to open a local session.

When does a desktop app stop being desktop?

Anthropic has changed the fundamental architecture of Cowork. New Cowork sessions now run remotely by default as the rollout reaches users. The agent loop and code execution run on Anthropic’s servers and the session is saved to your Claude account. Local execution still exists for existing desktop deployments.[1]

That has some obvious advantages, a Cowork task can continue when your laptop closes. You can start something on desktop and pick it up on mobile or the web, and your sessions follow the account rather than being trapped on one computer.[2]

For someone with one laptop, that may be an improvement.

For someone with several machines containing different local working environments, it changes the problem completely.

A remote Cowork session can still access local files, but it does so through the Claude Desktop application running on the particular computer containing those files. Anthropic describes the route explicitly: when a remote session needs a local file, the request travels through the Desktop app on that device, and only connected folders are available.[1]

So for those who don’t know, the architecture is now roughly this:

Claude account → remote Cowork session → Claude Desktop bridge → files on a particular machine.

That is very different from:

Claude Desktop → local Cowork → files on that machine.

The interface does a remarkably good job of making those two things look like the same thing, they are not.

One other particularly annoying thing I found is that Anthropic’s own current documentation is inconsistent. Their architecture page, updated this week, says Cowork runs in the cloud by default. Yet their current Claude Desktop installation page still says Cowork “runs code in an isolated virtual machine on your computer”. That’s reassuring.

The files weren’t the problem

Fortunately, I have Git backups of everything so nothing was lost or unreachable but that wasn’t really the point.

The problem was that I had a lot of design work created during heavy operational use of Cowork including Python renderers, shared design components, reference material and all the accumulated bits that turn individual files into a working system.

If those things only worked because Claude knew where they were, or because a particular Cowork session happened to have access to them, I didn’t have a resilient system, I had a dependency I hadn’t properly identified.

This is the distinction between backup and disaster recovery that I think gets missed.

A backup answers:

Can I get my files back?

Disaster recovery asks:

Can I still operate if this machine, application, platform or architecture changes underneath me?

Those are not remotely the same question.

So I tested it

One of the things in the estate is a Python renderer for a series of graphics I built with Claude. I pulled one out and gave it to a completely different AI system.

Could it read it? Yes.

Could it run it? Thankfully, also yes.

The resulting image was very slightly different because the renderer relies on two shared files containing brand functions and path definitions, and I hadn’t supplied those yet. Temporary substitutes were enough to make the actual renderer execute and produce the design.

That was useful because it proved that my decision to do it like that was the right one.

The design wasn’t a Claude design. It was Python.

The parts preventing exact reproduction weren’t hidden inside Claude either. They were ordinary declared dependencies that simply needed to travel with the renderer.

Which meant I didn’t really have a problem, more a massive inconvenience. It also made me acutely aware that if people are relying on one environment to do everything you have a massive problem if anything changes and you have no backups, or disaster recovery plan.

The AI should not own the operating environment

Which brings me to my point, the answer has always been that everyone needs a portable estate.

  • Not Claude Desktop.

  • Not Cowork.

  • Not Claude Code.

  • Not one Windows machine.

A complete working structure that can live under version control somewhere off your machines and your chosen provider’s server. That turns the architecture around.

Instead of:

AI platform → working environment

it becomes:

working environment → whichever AI I choose to let operate on it

That is a much safer dependency.

It also means that if Anthropic changes Cowork again next month, which given the current rate of change would hardly be out of character, the underlying estate does not have to change with it.

This is what disaster recovery actually looks like

  • There is nothing particularly dramatic happening here.

  • No data was lost.

  • No hard drive failed yesterday.

  • Claude didn’t stop working.

  • Anthropic simply changed how a product worked.

  • That exposed a dependency.

Those are the failures worth looking at BEFORE it happens again, and it will, because they rarely announce themselves as failures. Everything still appears to work, the login works, the conversations are there, the interface looks familiar and your files still exist.

It is only when you try to operate across a different machine that you discover which parts of your working environment belong to you and which parts only appeared to.

Anthropic’s own documentation now says remote Cowork sessions run on its infrastructure, while access to local files depends on the Desktop application being open on the machine containing those connected folders.[3]

Neither decision is inherently unreasonable. The mistake would be designing my own operational continuity around either of them remaining unchanged.

That is why I keep coming back to methodology rather than tools.

  • Tools change.

  • Models change.

  • Interfaces change.

  • Execution moves from local to cloud.

  • Capabilities that did not exist three months ago become defaults, while assumptions you wrote down last week quietly become historical records.

The methodology layer has to survive all of that.

For me, that now means something very concrete: the important code, designs, rules, decisions, records and dependencies are already inside a portable estate I control. The AI gets access to that environment, or the parts of it I want to grant access to. The environment does not belong to the AI provider.

A backup protects what you remembered to save.

Disaster recovery is discovering what you actually need in order to continue operating, then making sure no single machine or platform gets to decide whether you still have it.

Rather annoyingly, I had to discover the dependency when spinning up a new laptop to find that the architecture had changed underneath me. To be fair, Anthropic began rolling out remote Cowork in July 2026, so the architectural change itself was not new; I only discovered its practical consequences when I installed a second machine.

Which, now I think about it, is probably the test I needed.

If the AI platform you use changed how it worked tomorrow, would your system move with you, or would you discover that the system was actually theirs?