OneDrive is not for active development projects Link to heading

Laptop screen exploding with fire, fragments of the OneDrive symbol, and physical files flying toward the viewer.

You create a folder in OneDrive, clone a repository, install dependencies, open the editor, and start working. It sounds like a good idea: if everything is in the cloud, then everything is protected.

Until the terminal gets slow. The editor starts lagging. OneDrive spends too much time “processing changes”.

Then the clearer warnings arrive: a folder with a sync error, a file that will not upload, an icon with a red circle and a white X, or even user reports of messages like “There are too many files in your OneDrive”. At that point, that “automatic backup” has become one more process competing with the build, the antivirus, the editor, the framework watcher, and the language runtime itself.

The problem is not that OneDrive is bad. It is very good at what it was made for: syncing documents, spreadsheets, PDFs, photos, work files, and relatively stable deliverables.

The mistake is treating an active project folder as if it were a document folder.

Modern projects are not just “code files”. They are running workspaces. The repository is only the stable part; around it, the toolchain creates dependencies, caches, binaries, indexes, virtual environments, temporary files, build outputs, downloaded packages, AI models, and thousands of small files that change all the time. Putting all of that inside a real-time synced folder asks the sync client to fight the development cycle itself.

The problem is not cloud, it is category Link to heading

A Word file changes a few times over an afternoon. A Node project can create tens of thousands of files when installing dependencies. A Python project can build a .venv with executables, scripts, installed packages, and caches. A TypeScript project can generate dist, .tsbuildinfo, and bundler caches. A workflow with Whisper or other local models can download large weights, create cache, and process audio files that are not necessarily project source.

These are different kinds of things.

OneDrive looks at the file system and tries to answer sync questions:

did this file change?
was it renamed?
was it deleted?
is it open?
is there a conflict with another machine?
is this path allowed?
does this item need to upload, download, or wait?

The development environment, at the same time, asks the opposite questions:

can I delete and recreate this cache directory?
can I generate thousands of small files now?
can I keep this lock open while installing?
can I watch every change with a watcher?
can I rewrite the build output every time a file is saved?

These two views can coexist, but they should not compete for the same floor all day.

Where this appears in the real world Link to heading

Node and TypeScript Link to heading

The Node ecosystem is the classic example. The node_modules folder is famous for being large, deep, and full of small files. Even simple projects can download hundreds of packages. Larger applications also bring tool caches, build outputs, and framework artifacts:

node_modules/
dist/
build/
.next/
.nuxt/
.vite/
.cache/
coverage/
*.tsbuildinfo

Those items are not the project’s “intellectual product”. In general, they can be recreated from package.json, lockfiles, and install/build commands.

GitHub’s own Node .gitignore template lists many of these paths as things to ignore, including node_modules/, caches, build outputs, and TypeScript incremental information files. The TypeScript documentation also explains that incremental saves project graph information in .tsbuildinfo files on disk.

That is great for speeding up local builds. It is terrible as continuous sync material.

Python Link to heading

Python has the same pattern, with different vocabulary.

A virtual environment (.venv, venv, env) is not just a configuration: it is a directory tree with executables, scripts, installed packages, and site-packages. The Python documentation describes venv as its own environment, created on top of a base installation, with specific directories for binaries and packages.

Python also creates common caches and artifacts:

.venv/
venv/
env/
__pycache__/
*.pyc
.pytest_cache/
.mypy_cache/
.ruff_cache/
dist/
build/
site/

Again: this matters locally, but it does not need to become real-time sync. What should be preserved is the code, pyproject.toml, requirements.txt, the lockfile when one exists, the documentation, and the data that truly belongs to the project.

Local AI, Whisper, and downloaded models Link to heading

With local AI, the situation becomes more visible because some artifacts are not only numerous, but also large.

Whisper, for example, is installed as a Python package and has models ranging from tiny to large and turbo, with approximate VRAM requirements that OpenAI’s documentation lists from about 1 GB to 10 GB depending on the model. The CLI also accepts --model_dir and, when it is not provided, uses ~/.cache/whisper by default to store models.

That does not mean you can never back up models. It means they should not accidentally enter the same sync pipeline as your source files.

A downloaded model, transcription cache, temporary raw audio, and intermediate processing output are different things from source code. Mixing all of that inside a synced folder makes OneDrive try to preserve what is often just reconstructable material.

Git Link to heading

Git deserves a separate mention.

The .git directory is a local database. It has objects, references, an index, locks, and frequent small changes. Git is already the right mechanism for versioning code. OneDrive is another mechanism, with different semantics, trying to observe and sync the internal files of that mechanism.

That does not mean every repository inside OneDrive will break. The point is simpler: you are stacking two state systems on top of the same folder. When something gets slow, stuck, or conflicted, diagnosis gets worse.

The healthier model is: Git versions the code; OneDrive, if it is part of the story, stores a filtered copy, a backup, a package, an export, or a controlled mirror.

What OneDrive recognizes as a limit Link to heading

Microsoft itself documents important OneDrive and SharePoint limitations.

Some are especially relevant for development:

for best performance, Microsoft recommends syncing no more than 300,000 total items across cloud storage;
performance issues may happen above that volume even when not all items are synced;
the full decoded path, including the file name, cannot exceed 400 characters in OneDrive and SharePoint;
some file and folder names are invalid or blocked;
temporary .tmp files are not synced;
OneDrive does not support using a network or mapped drive as the sync location, and it does not support syncing through symbolic links or junction points;
when there are many files or one large file, the client can spend a long time in “syncing” or “processing changes”.

There is also a public preview on Windows for scenarios of up to 1,000,000 items per sync instance, but it has specific requirements for system version, memory, SSD, processor, and Insider client. In other words: it is not a license to throw node_modules, .venv, AI cache, and monorepo build output inside OneDrive and call that architecture.

The most important limit is not only the number. It is the nature of the files.

One million organized PDFs that rarely change is one thing. A project that creates, deletes, and rewrites thousands of small files every few seconds is another.

The classic symptom: “processing changes” Link to heading

When OneDrive gets stuck on “Processing changes”, Microsoft’s support documentation lists causes such as an open file, many added files, a very large file, recent login, or a computer update.

For an ordinary user, that can happen when uploading a large photo folder.

For a developer, that can happen several times in the same day:

npm install;
pnpm install;
pip install;
python -m venv .venv;
pytest;
npm run build;
documentation generation;
search index creation;
AI model download;
audio transcription;
cleanup and recreation of dist.

Each tool is doing something legitimate. The problem is adding all of them to real-time sync.

When the problem becomes a visual error, Microsoft’s own documentation describes the red circle with a white X as a sign that a file or folder cannot be synced. And in Microsoft support discussions, there are also direct reports of the message “There are too many files in your OneDrive”. That distinction matters: the red icon is a documented client state; the exact sentence can vary depending on language, account, client version, and sync scenario.

The hidden SSD cost Link to heading

There is also a less visible effect: unnecessary disk writes.

Modern SSDs can handle a lot, so this should not become panic. But SSD endurance is not abstract. Manufacturers measure endurance using metrics such as TBW, for terabytes written, or DWPD, for drive writes per day. In simple terms: there is an amount of writes the manufacturer guarantees for that model within the warranty period.

When you let OneDrive sync node_modules, .venv, bundler cache, test cache, dist, build, and models downloaded by AI tools, you create a duplicated I/O pipeline. The development tool writes. The sync client observes, computes state, reads metadata, creates a queue, uploads, downloads, resolves conflicts, and may rewrite files. In some cases, the pattern of small random writes also increases the internal cost because of mechanisms such as garbage collection, wear leveling, and write amplification.

That does not mean a small project in OneDrive will destroy your SSD. The point is different: if dependencies, caches, and builds are disposable, spending disk writes to sync them is waste. On machines with a small, older, very full SSD, or machines already used for heavy workloads, that waste stops being merely theoretical.

The model that works better Link to heading

For local development on Windows, I prefer to separate responsibilities:

C:\Dev\
  project-a\
  project-b\
  project-c\

OneDrive\
  Backups\
  Deliverables\
  Documents\

Active code stays outside OneDrive. It can be C:\Dev, a Dev Drive on Windows 11, or another fast local volume. The remote repository lives on GitHub, GitLab, Azure DevOps, Bitbucket, or a private Git server. OneDrive enters as filtered backup, not as the live source.

This design has a boring and very valuable advantage: each tool does what it knows how to do.

Git handles history, branches, diffs, merges, and collaboration.
The local disk handles fast I/O for builds and dependencies.
OneDrive handles documents, deliverables, and backup.
rclone provides a controlled bridge when you want to mirror part of the environment.

What about Dev Drive? Link to heading

On Windows 11, Dev Drive is an interesting alternative for development workloads. Microsoft describes Dev Drive as a volume designed to improve performance for developer workloads, using ReFS and integration with Microsoft Defender performance mode.

It does not replace Git and it does not replace backup. It solves another part of the problem: reducing local friction for project files, builds, and dependencies.

A reasonable setup could be:

D:\Dev\                 # Dev Drive or fast local volume
  my-project\

OneDrive\DevMirror\     # filtered mirror, not the active workspace

If you do not use Windows 11 or do not want to create a Dev Drive, C:\Dev already helps a lot simply by leaving the synced folder.

Where rclone fits Link to heading

rclone is a copy and sync tool for file systems and cloud services. For OneDrive, it has its own backend, Microsoft authentication, hash support, listing, and specific options.

The most important part in this context is filtering.

Instead of sending the whole project tree to OneDrive, you define what stays out:

- **/node_modules/**
- **/.pnpm-store/**
- **/.venv/**
- **/venv/**
- **/env/**
- **/__pycache__/**
- **/.pytest_cache/**
- **/.mypy_cache/**
- **/.ruff_cache/**
- **/.cache/**
- **/.next/**
- **/.nuxt/**
- **/.vite/**
- **/dist/**
- **/build/**
- **/coverage/**
- **/public/**
- **/resources/_gen/**
- **/.git/**
- **/*.tsbuildinfo
- **/*.pyc
+ **

This is an example, not universal law. Each project has its own important and disposable directories.

The command should start in simulated mode:

rclone sync "C:\Dev" "onedrive:DevMirror" `
  --filter-from "C:\Dev\.sync\rclone-dev.filter" `
  --dry-run `
  --progress `
  --stats 10s

The complete PowerShell wrapper and rclone filter used in this design are in the blog examples repository: onedrive-projetos-desenvolvimento-rclone .

Only after reviewing what would be copied and what would be ignored does it make sense to remove --dry-run.

It is also worth thinking about whether you want sync or copy:

copy copies without deleting from the destination what disappeared from the source;
sync makes the destination mirror the source, including removals;
--delete-excluded must be treated very carefully, because it tells the destination to delete files that now match excluded filters.

The rclone documentation is direct on this point: filters are powerful, but order, relative root, and ** matter. Before trusting them, use --dry-run, -v, and, when necessary, --dump filters.

What to sync Link to heading

A practical rule:

Sync what you wrote, configured, or received as real input.

Examples:

src/
docs/
content/
scripts/
tests/
README.md
package.json
package-lock.json
pnpm-lock.yaml
pyproject.toml
requirements.txt
uv.lock
poetry.lock
.env.example

Do not sync what the machine recreates.

Examples:

node_modules/
.venv/
__pycache__/
.pytest_cache/
.mypy_cache/
.ruff_cache/
.next/
.vite/
dist/
build/
coverage/
.git/
*.tsbuildinfo

Are there exceptions? Of course. A project may have a dist that is the final deliverable for a client, a build that contains a signed package, or a local model that you cannot easily download again. But the exception needs to be conscious. If everything is an exception, the filter does not exist.

What I would do in practice Link to heading

For a Windows development machine, my recommended flow is:

Create a local root for code, such as C:\Dev.
Clone repositories there, outside OneDrive.
Use the Git remote as the source of truth for code.
Keep .gitignore well maintained.
Use OneDrive for documents, deliverables, and filtered backups.
Create an rclone filter to exclude dependencies, caches, builds, and .git.
Run rclone with --dry-run first.
Automate the mirror only after the report is clean.
Separate folders for large data, models, and raw media by intent: source, cache, deliverable, or temporary.

This is not as magical as “throw everything into OneDrive”. But it is much more predictable.

Quick checklist Link to heading

Before placing a project inside any real-time sync client, ask:

Does this folder have node_modules?
Does it have .venv?
Does it have .git?
Does it have incremental build?
Does it have bundler cache?
Does it have AI models?
Does it have raw audio, video, or datasets?
Does it have thousands of small files?
Does it have deep paths?
Does it have files being rewritten by watchers?
Does it have cache or build output constantly writing to the SSD?

If the answer to two or three of those questions is “yes”, the best place for active development is probably not OneDrive.

Use OneDrive as a vault, not as a workbench.

The workbench has tools in use, temporary mess, sawdust, and experiments. The vault has what needs to be preserved.

Source code lives very well with Git. Dependencies live very well being reinstalled. Cache lives very well being deleted. Backup works better when it is intentional.

Developer work gets lighter when those boundaries are clear.