Google Drive’s documented web workflow copies files, not folders. If you need a flat collection in a new location, you can create a destination folder and copy selected files into it. That produces separate file copies, not a verified duplicate of the original folder tree and every subfolder.
For a small, flat set of files, use the manual process below and verify the result. For nested folders or recurring copies, treat the task as a folder-and-file mapping operation. Drive for desktop synchronization is a separate choice: it makes files available locally, but it does not by itself create a second cloud folder.
Google’s Drive Help documentation explains how to copy files and states that users cannot copy folders through the described web workflow.
A copied set of files is not necessarily a copied folder tree. Choose the method according to the structure that must exist at the destination.
Can you copy a folder in Google Drive?
Google’s current Help documentation supports making copies of files, not folders, through the documented Drive web workflow. It does not provide a native web command for duplicating a parent folder and all of its descendants.
These outcomes are different:
- Flat file copy: a new folder contains copies of selected files from one source folder.
- Folder-tree copy: destination folders are created to match the source structure, and files are copied into their corresponding locations. This requires multiple operations and checks.
- Local synchronized copy: Drive for desktop makes files available on a computer. Synchronization settings do not themselves create a second cloud folder.
Decide which outcome you need before selecting items. A flat copy is a manual file operation. A nested or repeatable copy needs an inventory, mapping rules, exception handling, and a completion check.
Copy files into a new folder: a manual workaround
This approach is suitable for a small, flat group of files when you can inspect the destination. Google documents making a copy of an individual file, copying and pasting files, creating folders, and moving items. It does not establish that every account or file type responds identically to a multi-select operation, so test a representative sample first.
Google documents the individual file operations, not this entire sequence as a universal multi-file recipe. If a file cannot be copied or its destination is unclear, exclude it from the completed count, record the issue, and assign it to the person performing the copy. This process does not copy subfolders.
If the folder contains subfolders, plan a tree copy
A nested copy is a set of container-creation and file-copy operations, not one verified native Drive web command. Each source folder needs a corresponding destination folder, and each source file needs a copied destination file inside the mapped destination folder.
Before starting, inventory the source tree and decide how to handle inaccessible items, shortcuts, shared-drive locations, name collisions, destination access, and sharing requirements. Do not assume that copied items retain every permission, ownership rule, shortcut behavior, or shared-drive property.
Proceed level by level: create destination folders, record their identifiers, copy files into the mapped destinations, and reconcile expected and actual counts as you go. Validate that the destination is not inside the source, that the user can create items there, and that the naming policy is explicit. If an item cannot be inspected or its behavior is unclear, assign it to a named owner instead of silently skipping it.
Use stable Drive identifiers rather than filenames alone. Names can collide or change, while a source-folder-to-destination-folder mapping lets you place each copied file in the intended branch and explain exceptions.
For an operational record, one file-mapping row should represent one source file copied during one requested operation. The following is an illustrative tracking record, not a Google Drive or Zapier data format:
{
"operation_id": "illustrative-run-014",
"source_file_id": "illustrative-source-id",
"destination_file_id": null,
"status": "needs_manual_verification"
}A folder-mapping row should instead identify one source folder and its destination folder. Keep operation-level summaries separate from item-level observations. Record stable IDs or Drive links where available, along with status and error details. A filename alone is not a safe deduplication key.
Drive for desktop: syncing is not the same as duplicating
Google documents two My Drive modes in Drive for desktop:
- Streaming: files remain primarily in the cloud and download when needed, generally using less local disk space.
- Mirroring: a full local copy of My Drive is stored on the computer and uses local disk space.
Choose between them based on local storage and offline-access needs, not on an assumed folder-duplication command. Google’s documentation does not verify a universal Finder or File Explorer “Duplicate” workflow that recursively creates a second Drive folder on every platform.
If you make local changes, check Drive for desktop’s synchronization status and wait for synchronization to finish before assuming the web copy reflects those changes. Shared drives and other locations can have different mode availability, so check the documented settings for the relevant location. See Google’s references for streaming, mirroring, and synchronization and Drive for desktop settings.
For recurring or large copies, design the operation before automating it
Zapier’s Google Drive integration page lists file- and folder-related triggers and actions, including creating a folder and copying a file. Those listings do not establish a ready-made recursive folder-copy action, guaranteed subfolder traversal, permission replication, or identical behavior for every account and Drive location.
A proposed workflow would accept a source folder, destination parent, naming policy, and copy policy. It would need to discover the source items, create destination folders, map source IDs to destination IDs, copy files, and record outcomes. Test the actual actions and fields for the connected account before treating the design as operational.
For repeated work, define the run policy. A new-snapshot policy creates a fresh destination for each approved run. A skip-already-copied policy requires a stable mapping between the operation and its source items. These are design choices, not vendor-defined behaviors.
AI can classify a request as a flat copy or a nested tree copy and propose a source, destination, naming rule, and expected item list. Fixed rules should control identifiers, destination selection, collision handling, deduplication, and execution. Do not let an AI system silently infer IDs or make sharing, move, or delete decisions.
Zapier automation consulting may be relevant when evaluating a tested repeatable workflow. AI agent design is relevant only when an AI client participates in an approval-based process.
Zapier MCP is an authorized action layer for compatible clients to call selected Zapier tools. It is not a prebuilt folder-copy workflow and does not automatically provide approval, duplicate prevention, or result reconciliation. If MCP is used, expose only the actions required for the approved process and show the proposed source, destination, naming rule, and expected item count before execution.
Prevent duplicate runs and verify the result
Separate one requested operation from its individual folder and file records. A proposed file-copy intent can use operation_id + source_file_id as its grain. A folder mapping can use operation_id + source_folder_id. If a repeated policy intentionally creates a new snapshot, include the destination parent or snapshot identifier in the uniqueness rule. These are implementation patterns, not Google or Zapier fields.
If concurrent runs are possible, a lookup followed by create can race. Use a database-enforced unique constraint or a transactional upsert where the system supports it. Do not treat a filename, a copy-name prefix, or a successful action submission as proof that an item is unique or complete.
Do not mark a run complete until destination mappings and counts have been checked. Review failed and skipped items, name collisions, destination access, synchronization status where applicable, and any difference between expected and actual results.
- Source, destination, operation policy, and collision rule are recorded.
- Expected folder and file counts are recorded before execution.
- Every required source item has a destination mapping or a documented exception.
- Destination access, sharing expectations, and synchronization status have been checked.
- Permission errors, inaccessible items, collisions, and count mismatches have a named human owner.
Measure success at the correct scope: report operation-level completion separately from item-level failures. Useful measures include completion rate, unresolved item count, duplicate count, and time to reconcile exceptions. The right method depends on whether you need a flat set of copied files, a reconstructed folder tree, or synchronized local files.