OpenClaw or Claude Cowork? Here's How to Plug Both Into the Same Brain

This post was originally published on my Substack publication as OpenClaw or Claude Cowork? Here's How to Plug Both Into the Same Brain.

If you work with AI regularly, you've probably hit this same wall.

I've been running OpenClaw on a cloud server for a while. It's autonomous, always on, and handles heavy-lift work like drafting business plans and processing research while I sleep. Mia Kiraki has been deep in Claude Cowork, using it constantly for writing, brainstorming, workflow building, and managing her systems locally on her laptop.

That's why Mia Kiraki is joining me today to go over how to connect two of the most used AI agent frameworks.

We both got curious about the other side.

I wanted to bring Claude Cowork into my setup and see what local AI could do for me. Mia wanted to experiment with OpenClaw and tap into the power of a cloud agent that never sleeps.

But the moment we tried to cross over, we hit the wall: our tools couldn't see each other's work.

OpenClaw would generate something brilliant on my server, and Mia's local Claude session had zero awareness it existed. The reverse was just as bad. Two powerful AIs, completely siloed, with us playing messenger pigeon between them.

So instead of just swapping tools, we decided to connect them through a real, permanent bridge between cloud AI and local AI that didn't leak our data to a third party or drain our wallets on token usage.

Mia was the first to flag this. She'd been trying to use Notion as a shared knowledge base and kept running into the same friction: proprietary databases, opaque storage formats, and the constant overhead of API calls every time an AI needed to "think" about her notes.

The math doesn't work.

Every time your AI searches a Notion database or queries an AFFiNE page block, you're burning API tokens. Scale that to a real workflow - dozens of queries per session, multiple sessions per day - and the costs pile up fast. Worse, your most private strategies and unreleased ideas are sitting on corporate servers where terms of service can change overnight.

We wanted something that stored everything as plain .md text files, synced instantly, and let both AIs read directly without any API overhead.

That something turned out to be Nextcloud.

Think of Nextcloud as your own self-hosted Dropbox, except you own the server and control every byte.

It lives on a cheap VPS that you rent (Hetzner, Linode, DigitalOcean; a few dollars a month). We use a Hetzner CX33 server and a CX23 server. It stores your files as raw Markdown and it syncs those files between your server and your local machine in real time.

What really great about this is that because the data exists as pure text in two places simultaneously (on the server and on your local drive), your AIs don't need APIs to communicate.

My cloud AI (OpenClaw) reads files directly off the VPS. Mia's local AI (Claude Cowork) reads the same files right off her hard drive through the synced folder.

Both AIs share a unified, real-time knowledge base. It's private, instantaneous, and costs zero API tokens.

Mia called it "giving both AIs the same notebook."

I'll be upfront: self-hosting sounds intimidating. Servers, Linux, Docker, reverse proxies, it all reads like a part-time job.

It's not.

You just need a blank VPS and a conversational AI to act as your personal sysadmin. You manage the conversation; the AI writes the commands.

Here's the exact prompt Mia used to get Nextcloud running:

You are an expert Linux SysAdmin with full access to a freshly purchased, blank Ubuntu VPS. Your job is to **actually perform** every step yourself — do not explain or instruct. Just execute.

Complete the following tasks autonomously:

1. Install Docker and Docker Compose on this machine.
2. Create a `docker-compose.yml` file that runs Nextcloud with a database, configured securely with auto-restarts.
3. Start the containers.
4. Confirm the service is running and report the URL where the Nextcloud admin setup page can be accessed.

Use your tools to run every terminal command directly. Do not ask for confirmation between steps. If a step fails, diagnose and fix it automatically. When finished, report what was done and the final access URL.

Feed that to your Openclaw assistant that is running in the same VPS as your future Nextcloud setup. I suggest you use a smart model for this, preferably Opus but I got it working with both Gemini 3.1 Pro and Kimi K2.5.

You'll have Nextcloud running in under 5 minutes.

Your Nextcloud is running on the server, but it's still locked inside it. To reach it from a browser, your phone, or anywhere else, you need to punch a secure tunnel from your VPS to the internet.

We use Cloudflare Tunnel for this. It's free, takes five minutes, and never exposes your server's IP address directly.

What you need first:

• A free Cloudflare account
• A domain name managed by Cloudflare

Once your domain is live on Cloudflare, hand the rest to OpenClaw:

A Nextcloud instance is running on this Ubuntu server and needs to be accessible from the internet via a Cloudflare Tunnel. Perform the following autonomously without asking for confirmation.

1. Install `cloudflared` on this server.
2. Authenticate with Cloudflare and create a named tunnel.
3. Configure the tunnel to route traffic from a public subdomain (e.g. `nextcloud.yourdomain.com`) to the local Nextcloud service.
4. Install the tunnel as a system service so it starts automatically on reboot.
5. Confirm the tunnel is active and report the public URL where Nextcloud is now reachable.

If any step fails, diagnose and fix it before continuing. When finished, verify Nextcloud loads correctly at the public URL.

During setup, Openclaw will provide you with a URL that you must open in order for Cloudflare to authorize it. But that's basically all you have to do manually.

When it's done, you'll have a clean https://nextcloud.yourdomain.com URL - SSL included, no port numbers, no exposed IP. That's the address you'll use for browser access, the desktop sync client, and WebDAV connections from your AIs.

Once the server is live, log into Nextcloud through your browser and do two things:

1. First, create a dedicated admin account for AI access. Name it something like ai-admin or bot as this keeps your personal account separate from what the AIs touch.

2. Second, create a clean directory that will serve as the single source of truth for your shared brain. I use /docs. This is the folder both AIs will read from and write to.

When you hit a technical wall, don't Google it. Copy the exact error message, paste it to your Openclaw, and let it give you the fix.

For example, Nextcloud has a notorious error with external storage mounts. If you see "Storage is temporarily not available" or "No data directory set," paste this prompt:

My Nextcloud instance is experiencing external storage errors: "Storage is temporarily not available" or "No data directory set". **Fix this autonomously without asking for confirmation.**

The Nextcloud container name is `nextcloud-app-1`. The target data directory is `/workspace`.

Perform the following tasks using your tools:

1. Run `docker exec` with `occ files_external:list` to identify the affected mount ID.
2. Use `occ` to set the `datadir` for that mount to `/workspace`.
3. Set correct Linux ownership to `www-data:www-data` and permissions to `755` on the `/workspace` directory.

Execute each command directly. If any step fails, diagnose the root cause and fix it before moving on. When complete, verify the mount is healthy and report the outcome.

This "paste the error, get the fix" pattern works for almost every issue you'll encounter.

If you're running a cloud AI alongside Nextcloud on the same server, you'll eventually hit a "Permission Denied" error when trying to save a file through the Nextcloud web interface. This tripped us up for a while, so let me explain it plainly.

You have two workers touching the same files:

1. The AI (typically running as root, the computer's top-level user)

2. Nextcloud (running as www-data, a limited web worker)

When the AI creates or modifies a file, it locks it under its own identity. Later, when Nextcloud tries to edit that same file, it gets blocked and throws an error.

The fix is a permanent "house rule" for the shared folder. Instead of manually unlocking files each time, you apply an Access Control List that says: "No matter who creates a file in here, Nextcloud always gets edit access."

Here's the prompt:

I have a permission conflict exists between Nextcloud (`www-data`) and an AI agent that shares the `/root/.openclaw/` directory. **Resolve this autonomously without asking for confirmation.**

Apply a permanent ACL house rule to `/root/.openclaw/` that grants the `www-data` group full read, write, and execute permissions on all current files and any files created in the future.

1. Apply default ACL rules so all future files inherit `www-data` group permissions automatically.
2. Apply the same rules recursively to all existing files and subdirectories right now.
3. Verify the ACLs were applied correctly by inspecting the result.

Execute every command directly. If `acl` tooling is not installed, install it first, then proceed. Report the final verified state of the ACL on the directory when done.

Run that once and the conflict goes away permanently.

Now that the server is alive, we need to bridge it to your actual computer.

Download the official Nextcloud desktop client for your Mac or Windows machine. Skip third-party sync plugins, as the native client is more stable and handles conflict resolution properly.

Open the app, navigate to "Add Folder Sync Connection," and map the remote docs folder to a local folder on your machine. I use Documents/NextCloud. Mia uses a similar path on hers.

Once connected, the sync is invisible. Any file OpenClaw creates on my server appears locally within seconds. Anything Mia writes in her local folder shoots back up to the server immediately. No refresh buttons, no manual syncing. It just works.

This is where the whole thing comes together.

Since Nextcloud syncs everything to a native folder on your machine, connecting Claude Cowork is dead simple. Just point it to your synced Documents/NextCloud folder. No API keys, no authentication, no latency. Claude reads the files directly off your hard drive.

Mia figured out this connection early on and it changed her entire workflow. She can ask Claude to reference, review, or build on anything OpenClaw has written, without ever touching a server or an API.

On the server side, it's even easier. Since OpenClaw lives on the same machine as Nextcloud, it accesses files instantly through a shared Docker volume, or via Nextcloud's built-in WebDAV endpoint, just ask it:

Create a new "Test" file and share it in the NextCloud /docs. Share the link with me once you are done.

Here's a real scenario. I'm out for a walk. I pull out my phone, open Telegram, and message OpenClaw: "Draft a business plan snippet based on the meeting notes in my docs."

OpenClaw fires up on the server, generates the Markdown file, and saves it to the Nextcloud folder.

By the time I'm home and at my laptop, that file is already synced locally. Mia can open Claude Cowork on her machine and say, "Review the business plan Dan's AI just wrote," and Claude reads it instantly off her local drive.

Two AIs, two humans, one shared brain. No copy-pasting, no file transfers, no API calls.

You might have noticed we haven't mentioned an actual note-taking app yet. That's by design, the architecture is just AIs reading raw .md files.

But raw Markdown is ugly for humans to read. This is where Obsidian comes in.

Obsidian isn't storing your data. It's a viewer, a pair of glasses that renders your .md files with proper headers, links, and formatting, without changing the underlying file type or locking you into a database.

Download Obsidian, click "Open folder as vault," and select your synced Documents/NextCloud folder. You're now browsing the exact same files the AIs are reading.

Or you can just use the built NextCloud interface, it works great for .md files but it's rather hard to move around docs.

Want your brain in your pocket? Just go to your NextCloud URL and start editing. Everything is in sync with your local computer so when you get back to your laptop you can continue where you left off.

Let me lay out why plain-text-over-Nextcloud beats every alternative we tried.

Token efficiency. Reading raw Markdown is the cheapest, fastest way for an LLM to digest a knowledge base. You completely bypass the massive token drain of querying Notion databases or parsing proprietary formats. Pure text wins every time.

True data ownership. No SaaS company is mining your second brain. No terms of service can change overnight and lock you out of your own notes. The files are plain text on a server you control.

Zero-cost AI communication. Both AIs read native files. No API calls between them, no token usage for "searching" your notes. The sync is handled at the filesystem level, not the application level.

Because it's all plain text on your own server, securing it permanently is one more prompt away:

A Nextcloud instance is running on this Ubuntu server. **Perform the following backup automation tasks autonomously, without asking for confirmation.**

Create and deploy a production-ready nightly backup system:

1. Locate the Nextcloud data directory on this server, then write a bash script that compresses it into a timestamped archive and securely uploads it to an AWS S3 bucket (or Backblaze B2 if S3 is unavailable). The script should clean up the local archive after a successful upload.
2. Save the script to an appropriate location on this server, set correct execute permissions, and verify it runs without errors.
3. Register the script in the server's crontab to execute automatically every night at 3:00 AM.
4. Confirm the cron entry is active and report the full backup pipeline - script location, upload destination, and schedule.

If any required CLI tools (`aws`, `zip`, `b2`) are missing, install them before proceeding. If credentials are needed, prompt for them once at the start and proceed immediately after.

Once the Nextcloud sync was running and both AIs were plugged in, we realized we'd accidentally built something bigger than an AI memory system.

We shared a folder between our drives.

It sounds almost too simple to mention, but think about what that means.

Mia and I each have a Nextcloud sync client pointed at the same remote folder on the VPS.

When I drop a document into that folder on my machine, it syncs to the server and then down to Mia's laptop automatically, encrypted in transit. When she edits it and saves, the changes flow right back.

We synced our AIs and we built our own private network hub.

No Google Drive. No Dropbox. No shared Notion workspace with a corporate middleman reading our data. Just two laptops, one VPS, and a sync protocol. We control the server, we control the encryption, we control who has access.

If we wanted to add a third collaborator tomorrow, it's one new Nextcloud account and one more sync client, that's it.

The AIs ride on top of this same infrastructure. OpenClaw on the server can process files that either of us drops in. Claude Cowork on either of our laptops can read and build on anything the other person (or either AI) has written. It's a full collaboration layer - human to human, human to AI, AI to AI - running on plain text files and a sync protocol we own.

We started this project to bridge two AI tools. We ended up building a private, self-hosted collaboration network that happens to have AI superpowers baked in.

I built the server infrastructure, Nextcloud deployment, OpenClaw integration, and the sync architecture. Mia Kiraki refined the prompting strategies that make this whole setup accessible to non-technical users, and pushed the idea that our two AI worlds should talk to each other in the first place.

The whole project started because we each wanted to try what the other had. Turns out the best way to do that was to connect everything.