Warn or block active dev workspaces inside cloud-synced folders

Summary

This is an existing footgun likely to trap even sophisticated users, and it will become more common as less technical users adopt Codex.

Codex can operate inside folders managed by OneDrive, Dropbox, Google Drive, iCloud, etc. If it creates or uses active development artifacts there, especially .git, node_modules, build outputs, render caches, or large numbers of generated files, it can break or severely degrade cloud backup behavior. The user may only see vague sync states like "uploading 0 KB," thousands of pending changes, high memory/CPU usage, delete/restore prompts, or apparent system instability.

This should not be treated as a normal workspace choice. It should be a guarded opt-in.

Observed Problem

A Codex workspace inside OneDrive accumulated thousands of Git object files and generated artifacts. OneDrive became stuck processing/uploading thousands of changes, consumed substantial memory, and repeatedly asked the user to approve deletion of thousands of incomprehensible generated filenames. The underlying issue was not obvious from the OneDrive UI.

The fix required diagnosing OneDrive logs/state, identifying .git\objects churn, running Git cleanup, approving cloud-side deletes, and establishing a rule that active Git/build work should live outside OneDrive.

Most users will not be able to diagnose this.

Why This Matters

Cloud sync systems are designed for human files and relatively stable documents. They are poor default targets for high-churn development internals:

• .git\objects
• .git lock/index/reflog churn
• node_modules
• build caches
• render previews
• QA screenshots
• generated intermediate artifacts
• temp export folders

These files are often ephemeral, reproducible, or better backed up through GitHub/remotes, not OneDrive/Dropbox/GDrive. Syncing them creates operational risk without meaningful user benefit.

Expected Behavior

Codex should detect when a selected workspace is inside a known cloud-sync root and avoid using it as an active development workspace by default.

Examples:

• OneDrive
• Dropbox
• Google Drive
• iCloud Drive
• Box or similar enterprise sync roots

Recommended UX

When the user selects a cloud-synced folder, Codex should show a strong warning near the top:

This folder is inside OneDrive/Dropbox/Google Drive/iCloud. Using it for Git repositories, dependency folders, or build artifacts is likely to cause problems with cloud backup and may contribute to system instability, including sync loops, high CPU or memory usage, file conflicts, and large delete/restore prompts.

Primary action:

Use recommended local workspace outside cloud sync

Secondary/advanced opt-in should require two separate confirmations:

• Allow active development workspace inside a cloud-synced folder
• I understand Git/build artifacts may break or slow cloud backup

A single warning is not enough. For less technical users, the warning will often appear before they understand the consequences.

Suggested Default Architecture

Codex should default to:

• active dev/build workspace outside cloud sync, e.g. %LOCALAPPDATA%, C:\tmp, or a Codex-managed local workspace
• Git history backed up through GitHub or another explicit remote
• final deliverables copied back to the user's chosen OneDrive/Dropbox/GDrive folder
• source notes, manifests, Office files, and selected durable artifacts preserved in cloud sync
• ephemeral build/runtime state kept out of cloud sync

Existing Workspace Detection

If Codex opens an existing folder inside cloud sync and finds .git, node_modules, or high-churn build directories, it should flag:

This workspace contains development internals inside a cloud-synced folder. This may cause cloud backup problems and system instability. Consider moving active development outside cloud sync and copying final outputs back.

Acceptance Criteria

• Codex detects common cloud-sync roots on Windows/macOS.
• Codex warns before creating .git, node_modules, or build-heavy workspaces inside those roots.
• Default action uses a non-sync local workspace.
• Cloud-sync workspace use requires explicit advanced opt-in.
• Final deliverables can still be copied/exported back to the user's synced folder.
• Existing .git repos inside cloud-sync roots are flagged as reliability risks.

Framing

This is not about forbidding advanced users from syncing repos. There are edge cases where someone may intentionally want that. But it should be a considered opt-in, not a trap discovered through cloud backup failure.