AutoSave disabled when opening SharePoint-synced files from Finder after macOS Tahoe 26.6 update

Confirming this issue — additional technical detail that may help narrow down the root cause

I'm experiencing the exact same behavior described in this thread, and wanted to share some additional diagnostic detail that might be useful, since it points to a possible contributing factor beyond a generic sync failure.

Environment:

• macOS Tahoe 26.6.2 (25G83)
• Mac mini
• OneDrive standalone install, version 26.153.0809.0004
• Microsoft Word, Version 16.112.3 (26090417) — issue persists after updating from 16.112.3 (26083020)

Symptoms (identical to those already reported):

• AutoSave toggle OFF when opening any .docx/.xlsx/.pptx file via double-click from Finder, even though the file is correctly synced (folder shows the cloud icon, manual save uploads correctly, sharing links work fine).
• Word reports "Saved on My Mac" instead of the OneDrive/SharePoint location.
• Manually enabling AutoSave prompts to "upload" the file, as if it had never been in the cloud.
• After that upload completes, closing and reopening the same file resets AutoSave to OFF again.
• Opening the same file via Word > File > Open > Online Locations correctly recognizes it as a cloud document and AutoSave works normally — this is consistent with what others have reported.
• Reproduced this with brand-new files created and saved directly from Word into the OneDrive folder, not just pre-existing files.

Ruled out (verified via terminal diagnostics):

• OneDrive File Provider extension is registered and enabled (pluginkit -m -A -p com.apple.fileprovider-nonui shows it active).
• The File Provider domain for the account is alive and healthy (fileproviderctl dump), with the affected file showing ul:uploaded status and no error counters.
• The UBF8T346G9.OfficeOneDriveSyncIntegration shared plist (the mechanism OneDrive uses to publish synced folder metadata to Office) is correctly populated with all my synced libraries, including the personal OneDrive root, updated same-day.

Possible contributing factor — Unicode normalization mismatch:
My organization's OneDrive folder name contains an accented character ("Gestión"). Comparing the on-disk path (as returned by Finder/the filesystem) against the MountPoint value stored in the OfficeOneDriveSyncIntegration plist, I found:

• On-disk path: NFD-normalized (decomposed: "o" + combining acute accent, \xcc\x81)
• Plist MountPoint value: NFC-normalized (precomposed "ó", \xc3\xb3)

Both strings are visually identical and normalize to the same value under NFC or NFD, but differ byte-for-byte. If Office performs a literal/byte-exact comparison rather than a Unicode-normalized one when matching a local path against known cloud-synced locations, this would explain why the cloud identity fails to resolve — while the underlying OneDrive sync engine (which doesn't need to do this comparison) keeps working normally.

I want to flag that I have not found confirmation that this is a necessary condition — other reports in this thread and the related Tech Community thread describe the same symptoms without mentioning accented folder names, so this appears to be, at most, a contributing factor in some environments (possibly organization/tenant names with non-ASCII characters), layered on top of whatever broader regression was introduced around the macOS Tahoe 26.6 update.

Happy to provide further diagnostic output (fileproviderctl dump, log traces) if useful for triage.

I've been experiencing the same problem on two separate Macs I use at my company since the last week of July. Despite writing to Microsoft support numerous times, they haven't even bothered to respond.

This is not a minor AutoSave inconvenience. It is a serious regression with a real risk of data loss and version conflicts.

We are now seeing this on multiple Macs in production.

The pattern is consistent:

• SharePoint document libraries are synced with OneDrive.
• A user opens an Excel or Word file normally from Finder.
• Office opens the file as “Saved to my Mac” instead of recognizing it as a SharePoint/OneDrive cloud document.
• AutoSave is disabled.
• Co-authoring and normal cloud-document awareness are effectively lost.
• Opening the same file through Office or SharePoint works correctly.

From the user’s perspective, nothing unusual has happened. They opened a SharePoint-synced file from Finder using a workflow that Microsoft has supported for years. There is no reasonable indication that Office has suddenly decided to treat that document as a local file.

That is exactly what makes this dangerous.

We already have several real-world cases of this behavior. A user can continue editing believing that SharePoint, AutoSave, co-authoring and version history are protecting their work, while Office has actually lost the cloud identity of the file.

This is not just a UI issue. It can lead to conflicting document versions, missed changes from other users and potentially lost work.

What makes the timing particularly concerning is Microsoft’s current rollout of the new OneDrive Native Sync Engine for macOS.

Microsoft explicitly states that the new engine changes the OneDrive and SharePoint integration with macOS and Finder. It introduces a redesigned sync architecture, changes how synced SharePoint libraries appear in Finder, and is intended to simplify the previous architecture.

I am not claiming that the Native Sync Engine has been proven to be the root cause. It has not. But given the timing and the exact point of failure, the relationship should be investigated properly rather than dismissed as an Office preference, cache issue, reinstall problem or user configuration issue.

The failure appears to be somewhere in the:

Finder → macOS File Provider → OneDrive → Office cloud-file identity handoff

The file may still exist inside the OneDrive sync location and may still synchronize at filesystem level, but Office no longer reliably recognizes that the Finder path represents a SharePoint/OneDrive cloud document. Office then treats it as a local file, displays “Saved to my Mac”, and disables AutoSave and cloud collaboration behavior.

This is also not an entirely unknown class of problem. Very similar Finder / “Saved to my Mac” / AutoSave failures have occurred with OneDrive for macOS before.

Therefore, “open the file from Office instead of Finder” is a temporary workaround, not a solution.

If Microsoft presents a SharePoint-synced Office document in Finder as a normal synced cloud file, then Office must reliably recognize its cloud identity when the user opens it.

Microsoft and Apple need to determine where the Finder / File Provider / OneDrive / Office handoff is failing and fix it.

Customers should not have to discover this problem through lost work or conflicting document versions.

For an enterprise collaboration platform, silently disabling the very mechanisms that are supposed to prevent data loss is not a cosmetic bug. It is a reliability failure.

And, somewhat ironically, when I tried to open a Microsoft support case for this issue this evening, the Microsoft 365 Admin Center itself was affected by an active Microsoft 365 service degradation.

Microsoft’s own Service Health notice states that administrators may experience authentication issues in the Microsoft 365 Admin Center, alongside impact to multiple Microsoft 365 services.

To be clear: the current Microsoft 365 outage is not the cause of this AutoSave problem. We observed the Finder/AutoSave issue before the current service incident started.

It simply means that, this evening, while trying to report a potentially data-loss-causing OneDrive/Office regression, the administrative support channel used to report it was itself degraded.

That is not exactly reassuring from a reliability perspective.

This is driving me absolutely mad. If it persists much longer, I’m going to lose it.

As a side note, I have noticed another serious consequence: If I open a file from Finder while colleagues are already working in it, Office treats it as a local file, so I cannot see that anyone else is editing it. If they are still in the file when I save and close it, my changes are not synchronised back to the SharePoint version.

Think I found the problem using Claude...

The root folder created by OneDrive must not contains any non-ASCII characters.

Switch OneDrive application to English (System settings > General > Language and region > Applications > + > OneDrive > English) and restart the app. Root folder should now be named "OneDrive - Shared Libraries - xxxxxx". Wait fot sync to complete. Open an Office doc. Autosave should be on now.

Any luck? Or resolutions or updates? Most of our users have that issue and aside from opening from online location or going to the web version and then opening using app, not much luck...

Have the same issue. macOS Tahoe 26.5.2, OneDrive 26.139.0720.0007 (Apple Silicon 26.5.2)

Excatly the same problem here on 5 mac !!

You’ve isolated this to the Finder launch path: the same SharePoint files retain cloud identity and AutoSave when opened through Office or SharePoint, but Finder hands them to Office as local files after the Tahoe update. Microsoft’s AutoSave guidance says files opened from Finder may need reopening from within Word, Excel, or PowerPoint, so “Saved to my Mac” does not indicate a SharePoint permission or sync failure. Use Open > Sites or SharePoint’s Open in Desktop App as the workaround; avoid Finder for collaborative editing while it reports a local location. Capture the macOS build, Office build, OneDrive version, affected library, and reproducible test file. Send feedback from the Office app and open a Microsoft 365 admin support case with those details and timestamps. Since reset, relink, Keychain cleanup, and File Provider checks made no difference, further local resets are unlikely to help; Microsoft needs to investigate the Finder-to-Office handoff.