Google Drive and Google Photos users - ACTION REQUIRED

Annoucements
1

Hi All

Rclone's internal client-ID will stop working in 2026 - please make your own

We recently received a notification from Google that Google will start charging for API requests on rclone's built in default client-ID for Google Drive and Google Photos. The timescale for this is "Later in 2026, following 90 days of notice".

Since we are many hundreds of times over the free quota this would mean that the rclone project would have to start spending lots of money on quota requests. We don't know exactly how much because Google haven't released the pricing yet, but millions of dollars per year seems likely.

What we are doing

  • Add a warning to rclone (in the next point release) if you are using the default client-ID something like

NOTICE: This remote uses rclone's shared Google Drive client_id, which is
being retired and will stop working during 2026. Create your own client_id
to avoid interruption: https://rclone.org/drive/#making-your-own-client-id

  • Post an update when we know when exactly the 90 days starts
  • Disable the default client-ID before the end of the 90 day period
  • Remove the default client-ID at the next release

What you need to do

  1. Check if you are using the default Google client-ID. You can do this using rclone config show YourDriveOrPhotosRemoteName:. If you have set client_id and client_secret already you have nothing to do. If they are blank or missing then follow the next steps. If you are using a service account you don't need to change anything.
  2. Stop any rclone processes (eg rclone mount) using YourDriveOrPhotosRemoteName:
  3. Make your own client_id and client_secret following the guide in the google drive backend docs and add it to your config.
  4. In step 11 run rclone config reconnect YourDriveOrPhotosRemoteName: and answer "Y" when it asks "Already have a token - refresh?". This part is important otherwise rclone won't actually use your new client_id/client_secret.
  5. Repeat for all your google drive and google photos remotes. You only need to make one client_id/client_secret - you can add this to all your remotes but you must also run rclone config reconnect on each of them.

We are still talking to Google about this but we don't think their plan will change other than the timescales.

Happy rcloning and sorry for the inconvenience

Nick

PS Feedback appreciated.

2 Likes
Rclone wrapper tool for Google Drive
ClientID automation : winter is coming = deadline closing in
ClientID automation : winter is coming = deadline closing in
Rclone Release v1.75.0
3

Hi,

I will be available and happy to assist those who get stuck creating their client ID.

1 Like
4

Should have been done ages ago! Glad I had mine setup this way to start with!

Kudos to you for letting us mooch off of yours for years!

5

Well, I wanted to make it easy for users to get going... You are right though @Turner it has been obvious for a while that something like this was coming due to the ever increasing difficulty of getting your client id verified. It took 3 months and $600 last time!

6

Thanks for the update and explanation. It's good to know this is a Google API policy change rather than an rclone issue. The migration guidance and timeline should help users prepare before access is affected.

1 Like
7

Always used mine, as using a shared one seemed a recipe for disaster.

I think rclone is handling this in the best possible way.

2 Likes
8

I was looking at this for the tasks.org android and desktop app. The author there said it would cost him between US$15k - $35k. Seems they have been treating you favourably. I suspect they will go on to charge everyone for API access at some point.

1 Like
9

I just stumbled on this thread while writing some scripts to help my with syncing my large Google Drive.

There is a class of users for whom "create your own client ID" is not possible, and I haven't seen it mentioned in this thread:

Accounts enrolled in Google's Advanced Protection Program (APP)

I'm one of them, and I tested this thoroughly today before posting.

Here's my experience. Personal Cloud project, Drive API enabled, OAuth consent screen configured, Desktop-app client, me as the app's sole author and user:

  • scope drive.readonly, publishing status "In production" -> Error 400: policy_enforced, "Access blocked: app is not approved by Advanced Protection"
  • same scope, status "Testing", my own address added as test user, scopes declared on the consent screen -> identical error
  • scope drive.file (non-sensitive tier) -> consent succeeds, token works

So APP blocks any unverified app requesting a sensitive or restricted scope.

It does not matter that I registered the client, that I'm the developer, or what the publishing status is. drive.file passes but is useless for sync. The token sees zero existing files (I checked: lsf and backend query return nothing until the app creates files or you pick them one by one in Google's Picker).

Before anyone suggests the usual fixes:

  • Verification is not the gate. Leaving the bureaucracy aside, client-ids that work under APP (rclone's, Thunderbird desktop's) belong to verified apps. But verification alone doesn't put you on the APP allowlist. Thunderbird for Android - same organization, same Gmail scope - has been blocked since 2024 (thunderbird/thunderbird-android#8256). The allowlist appears to be per-client-id, hand-curated, and unreachable. Even Google's own Apps Script CLI is blocked (google/clasp#946).
  • Service accounts: Tried but cannot see Shared-with-me, and need every folder shared to them by hand. Clumsy and not a proper mirror.
  • Workspace migration: Admin-trusted client IDs supposedly work under APP (not tested today to be honest), but moving a consumer account to Workspace orphans every Shared-with-me grant tied to the @gmailgmail identity, so it's not a reasonable workaround for most people, including myself.
  • Drive for Desktop: no Linux, no headless, no Shared-with-me, gdocs become stubs. Wholly inferior to rsync (which is why we are here).
  • App passwords: revoked under APP, and never covered the Drive API anyway.

Which leaves the uncomfortable conclusion: rclone's built-in client ID currently works for users like me because it's on Google's internal allowlist. When it's retired, APP users go from "works fine" to "no path at all".

If there is an open line to Google about this change: could this user class be put on the table? The fix on Google's side is small and already exists for Workspace - admins can mark a client ID as trusted. A consumer-account equivalent ("I am the author of this app, I trust it") would resolve it. Failing that, some successor to the allowlisted shared credential.

And if anyone here with Advanced Protection has successfully moved to their own client ID, I'd genuinely like to hear how, because I just spent a whole day on it and could not find any success stories elsewhere.

10

Thanks for the report @ptu that is very useful feedback. I will send this to Google as a possible gotcha for the migration as I have an open ticket with them where we've been discussing the change.

1 Like
11

Would like to add a note on the implications re privacy of personal clientIDs, a fair warning.

A personal clientID "links" the account of the clientID to any other account accessing a remote. So, while google has user related information ("knowledge" of who accesses an account), the common clientID did not allow by its only use to establish links between remote accounts. Using a personal clientID from other person with your remote brings this linkage risk (not saying that google will link, but would have the means).

It them becomes essential to explain users that they should not use other person clientID and that if they have several remotes (limiting terms applying), if privacy concerns are important, they should create a per remote clientID ...

Not that the rclone team wished this to happen but this is how it goes

12

Just in case it might be of interest, I was shared the steps for personal ClientID creation in Spanish.

Paste 0_hK0bBdtLKq · NullPaste pass ClientID

Enjoy if that is your language, might be it can be incorporated somewhere in the website.

13

Have some doubts.

When created a private/personal ClientIDs following the guide, website warned that it might be needing verification as it does include sensible scopes ... What we can expect about this.... Has past experience showed that unverified ClientIDs become void after certain time lapse or usage?

Is adding a logo making unverified ClientIDs having shorter lifespans?

Are unverified ClientIDs having limits in terms of DRIVE remotes (accounts) being used in? I was unable to understand how the 100 users limit kicks in... - Later edit - looks clear that unverified ClientIDs (apps) have a 100 user limit cap - check here Unverified apps - Google Cloud Platform Console Help . User respecting Google account limits should be impacted. Some people might like to have a clientID per drive account though.

Certainly it looks that Alphabet is becoming restrictive in terms of free lunch, in storage, transactions, and expanding licensing income such as registering apps in the store and closing side mounting of apps... Removing generic ClientIDs for open/free apps seems another approach to that end, and, if not now, non verified clients are to be expected having short test times allowed and then removed... Let us see if gmail would soon charge per email sent/received... Time to budget paying for services if/when party is over and to start seeking other opportunities in the mean time...

TIA

Casper