Ditching the Cloud Drive: How I Built a Local AI Sync Workflow with Claude

I wrote previously about using Google Drive as a bridge to get my project files in front of Claude. It worked, but it had friction — uploading, waiting for sync, managing permissions, and always feeling one step removed from my actual codebase. So I replaced the whole thing with something leaner and faster: a PowerShell sync script, a protected Laravel endpoint, and a clear set of rules for how Claude and I work together. This post explains the setup and why it has become my preferred way to develop.

The Problem with Cloud Drive as a Middleman

Using Google Drive to share files with an AI assistant sounds convenient in theory. In practice it adds a layer of indirection that slows everything down. Files need to be uploaded manually or kept in sync through a desktop client. Folder structures do not always mirror your local project. You end up managing two versions of your work — the real one on your machine and the cloud copy Claude is reading from. When you are actively building something, that gap creates confusion and wasted time.

The real breakthrough came when I stopped thinking of the cloud as the source of truth and put my local machine back in charge. Everything Claude needs is already on my development machine. The question was simply how to expose it selectively and securely.

The Architecture: Two Workflows, One Clear Rule

The setup I landed on has two modes, and the rule for which to use is simple: if we are actively working on a file, I paste it directly into the chat. If Claude needs to browse something or fetch a file I have not shared yet, I run the sync script first and then paste the fetch URL. That is it. No cloud drive, no GitHub, no guessing at file contents from memory.

Primary workflow — copy and paste: This is the fastest and most reliable path. I paste the full file contents into the chat. Claude gives me back the complete updated file. I copy it straight into my editor and save. No intermediate steps, no version drift, no upload delay. For any file we are actively changing, this is always the preferred approach.

Secondary workflow — sync and fetch: When Claude needs to see a file I have not pasted, I run SyncToLaravel.ps1. This PowerShell script copies a defined subset of my local project into a protected storage location on my home-hosted Laravel server. Claude can then fetch any file from that location using a tokenised URL I paste directly into the chat. The token ensures nothing is publicly accessible, and the scope of what gets synced is explicitly defined — source code yes, vendor folders and images no.

What the Sync Script Does and Does Not Touch

One of the most important decisions in this setup was defining the sync boundary carefully. The script syncs the folders that matter for development: the application code, configuration, database migrations, routes, resources, and a special folder called ANOther where I keep style guides and notes for Claude. It deliberately excludes everything that would be wasteful or irrelevant — vendor dependencies, node modules, compiled public assets, images, PDFs, and a legacy views folder that is no longer in use.

This boundary serves two purposes. It keeps the sync fast, since only meaningful files are copied. And it keeps Claude focused — there is no risk of it referencing an outdated vendor file or a compiled asset as if it were source code.

The Protected Fetch Endpoint

On the Laravel side, a simple controller exposes two endpoints behind a long token: one to list all synced files, and one to fetch the contents of a specific file by path. The token is embedded in the URL itself, so sharing a fetch URL with Claude is as simple as pasting it into the chat. Claude reads the file, and we get to work.

There are a few quirks worth knowing about. File paths in the sync system must be lowercase — the underlying Flysystem library on Windows is case-sensitive for path lookups even though the operating system itself is not, which caused 404 errors until I learned to always use lowercase paths. If a file returns a 404 unexpectedly, restarting the local server clears Flysystem's directory cache and usually resolves it. These are small operational details, but knowing them in advance saves real debugging time.

Context Persistence Across Sessions

One limitation of working with Claude is that each new conversation starts fresh — there is no persistent memory of your project structure, your conventions, or your preferred way of working. The solution I use is a context document that I paste at the start of any new session. It covers the physical layout of the project, the sync rules, the tech stack, what is in scope and what is not, and the working agreement Claude and I follow. Pasting this at the start of a session takes seconds and means Claude is immediately oriented rather than spending the first several exchanges re-establishing the basics.

The style guides and project notes I keep in the ANOther folder serve a similar purpose — they give Claude a stable reference for how this specific project is built, what conventions apply, and what to avoid. It is the equivalent of a project wiki, kept right alongside the code and synced automatically.

Why This Works Better Than Cloud Drive

The cloud drive approach treated the AI assistant as something that lived in the cloud and needed files brought to it. This setup treats Claude as a collaborator that works on whatever I put in front of it, with my local machine remaining the single source of truth. The sync script is just a read-only window into that source — it never writes back, never creates branches, never interferes with the actual project.

The result is a workflow that is faster, more predictable, and easier to reason about. I know exactly what Claude has seen. I know exactly what it is working from. And when the session is over, the only thing that changed is the files I chose to save — because I copy-pasted them back myself.

Setting This Up for Your Own Project

The core components are straightforward to replicate. You need a sync script — PowerShell on Windows, a shell script on Mac or Linux — that copies your chosen source folders to a designated location on a machine Claude can reach over HTTPS. You need a simple protected endpoint on that machine that serves file contents by path. And you need a context document that describes your project and your working rules clearly enough that Claude can pick it up mid-conversation without confusion.

The investment is a few hours of setup. The return is a development workflow where your AI assistant is always working from real, current files — not approximations, not cached versions, not educated guesses. For anyone doing serious project work with Claude, it is worth building.