The associated forum post URL from https://forum.rclone.org

None yet. This came from implementing a cloud-agent workflow on top of an rclone VFS mount.

What is your current rclone version (output from rclone version)?

rclone v1.75.0-DEV
- os/version: ubuntu 26.04 (64 bit)
- os/kernel: 7.0.0-22-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.26.0
- go/linking: dynamic
- go/tags: none

What problem are you are trying to solve?

When rclone is mounted over a cloud backend such as OneDrive or SharePoint, the VFS cache automatically writes dirty files back to the remote after they are closed and the writeback delay expires. That is the right default for ordinary mounts, but it is risky for workflows where automated tools or AI agents edit the mounted tree.

The concrete use case is a cloud AI agent system:

1. The user mounts cloud storage with rclone VFS.
2. An agent edits files through normal filesystem APIs.
3. The human user wants to review/authorize the work before it is uploaded to the real cloud source of truth.

Today there is no explicit VFS staging mode for this. --vfs-write-back can delay uploads, but it cannot turn upload into an approval action. Once a file is closed and the delay expires, the remote content can be modified automatically.

This matters for shared, authoritative, audited, or production-backed cloud trees where an agent closing a file handle should not be enough to mutate remote content.

How do you think rclone should be changed to solve that?

Add an explicit manual writeback mode for the VFS cache.

Proposed behavior:

• Add --vfs-manual-writeback as a separate option rather than a new --vfs-cache-mode value.
• When enabled, dirty files remain staged in the local VFS cache after close instead of being uploaded automatically.
• Staged dirty files remain staged after restarting rclone with the same VFS cache.
• Existing VFS writeback behavior remains unchanged unless this option is explicitly enabled.
• If enabled with a cache mode lower than writes, promote the VFS cache mode to writes, since manual writeback needs a local write cache.

Proposed RC interface:

• vfs/dirty lists files staged for manual writeback.
• vfs/push file=path, vfs/push dir=path, or vfs/push all=true uploads approved staged files.
• vfs/revert file=path, vfs/revert dir=path, or vfs/revert all=true discards staged changes without uploading them.

Selector behavior:

• file, file2, ... select exact files.
• dir, dir2, ... select recursive directory prefixes.
• vfs/dirty with no selector lists all dirty staged files.
• vfs/push and vfs/revert require an explicit selector to avoid accidental bulk upload/discard.

Expected workflow:

rclone mount remote:path /mnt/work --vfs-cache-mode writes --vfs-manual-writeback --rc
# agent edits files in /mnt/work
rclone rc vfs/dirty
rclone rc vfs/push file=approved/file.txt
rclone rc vfs/revert dir=rejected-work

Why this is useful

This creates a review boundary between local agent/editor activity and remote cloud mutation:

• agents can work against normal filesystem APIs,
• remote cloud content is not changed automatically,
• the user can inspect the staged dirty set before upload,
• the user can approve individual files/directories,
• unwanted staged work can be discarded without uploading,
• staged work can survive rclone restart because it remains in the VFS cache.

This is especially useful for OneDrive/SharePoint-backed working trees used by AI coding or document-editing agents, where the user needs to authorize what becomes part of the remote source of truth.

Related implementation

A proposed implementation is open in PR #9509: #9509

It includes:

• --vfs-manual-writeback / vfs_manual_writeback,
• vfs/dirty, vfs/push, and vfs/revert RC commands,
• dirty cache reload behavior that preserves staged files instead of queueing uploads,
• docs in the VFS cache help,
• focused VFS/vfscache tests.

Tested with:

go test -count=1 ./vfs/...

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.