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

I am experiencing a persistent and fully reproducible issue with Microsoft 365 for Mac and OneDrive/SharePoint.

When I open a Word or Excel file stored in OneDrive or in a SharePoint library synchronized through OneDrive by double-clicking it in Finder, Office opens the file as if it were local:

• AutoSave is OFF
• the file is shown as saved locally / “Saved to my Mac”
• cloud-related features such as co-authoring do not work correctly

However, if I open the exact same file from within Word or Excel using Open > OneDrive / Online Locations / Sites, the file is immediately recognized as a cloud document:

• AutoSave is ON
• co-authoring works
• cloud functionality is restored

The behavior is therefore consistently reproducible:

Finder → OneDrive/SharePoint file → Office
= AutoSave OFF / file treated as local

Word or Excel → Open → OneDrive/SharePoint
= AutoSave ON / file correctly treated as cloud

This workflow had worked normally for a long time and stopped working after recent macOS / Microsoft 365 / OneDrive updates.

I have already updated macOS, Microsoft 365 and OneDrive, but the issue persists.

This appears to be related to the handoff between macOS Finder / Apple File Provider / OneDrive and Microsoft 365 for Mac rather than to a synchronization failure itself.

Could you please confirm whether this is now a known issue and, if so, whether a fix is planned or already being tested?

Given that the same issue is being reported by multiple Mac users, I would also ask that this case be escalated as a product-level issue rather than treated as an isolated local configuration problem.

I seem to have solved the issue on my machine – at least for the time being.

I deinstalled OneDrive, then navigated to these folders:

~/Library/Application Support/
~/Library/Caches/
~/Library/Containers/
~/Library/Cookies/
~/Library/LaunchAgents/
~/Library/Preferences/
~/Library/Logs/
~/Library/CloudStorage/OneDrive-Personal/


Within these folders, I deleted all files and folders that had "onedrive" in their name. 

Then reinstalled OneDrive. Seems to work for the time being.

Now that we're on Golden Gate 27.0, this issue unfortunately still persists. This appears to leave Apple out of the picture and suggests that the problem is solely on Microsoft's end. The issue has also made it significantly more difficult for me to carry out my day-to-day work and I think this applies to many of us in here. MS needs to fix this and we need them to do it ASAP!

Same problem here (including me and 3 of my clients) with Mac OS Tahoe 26.7 or Golden Gate 27.0. This it how it looks, when a file is directly opened in finder (wrong):

And this is how it looks when opened with the workaround (show online locations for saving):

Opened a case with Microsoft support and wait for their reply.

We've been experiencing this problem on two separate Mac computers since the last week of July, and we've stopped using Macs altogether. The entire company's operations have been disrupted. I've written to Microsoft numerous times but received no response. I'm checking here as well, but there doesn't seem to be a clear solution.

Hi,

Possible correlation found: OneDrive version pinned to old Sync Engine avoids the AutoSave issue

We've been affected by this exact issue (AutoSave disabled / "Saved to my Mac" when opening SharePoint-synced files from Finder) on a Mac running macOS Tahoe with a work/school account syncing SharePoint document libraries.

What we did:

- Used a script to pin/block OneDrive updates at version 25.243.1211.0001 (Standalone, Apple Silicon)

- Tested on macOS Tahoe 26.7

- Result: AutoSave works correctly and persists after a full restart

What we noticed in Finder that may explain why:

Our synced SharePoint libraries still appear grouped under a single root entry ("OneDrive - Shared Libraries - [org name]") in the Finder sidebar, rather than each library appearing as its own separate root.

According to Microsoft's Message Center post MC1458483 (OneDrive macOS Native Sync Engine, published Aug 21 2026), one of the explicit changes introduced by the new Native Sync Engine is:

"For users in organizations still using synced SharePoint libraries, this new sync engine now makes each synced library appear as its own root in the Finder sidebar, instead of nested under a single organization entry."

Since our libraries are still grouped (old behavior), this suggests our device has NOT yet been migrated to the Native Sync Engine, and that pinning the OneDrive app version may have prevented (or coincided with avoiding) that migration.

Hypothesis: the AutoSave/"Saved to my Mac" regression may be tied to the rollout of the Native Sync Engine on macOS Tahoe rather than to a specific OneDrive app build. This would explain why the bug has been reported across many different OneDrive versions (26.007.x, 26.055.x, 26.153.x, etc.) with no single "bad" build identified, and why some users report inconsistent results when just changing app versions.

Could anyone from Microsoft confirm:

1. Whether the Native Sync Engine rollout is tied to the OneDrive app version, the tenant, or the individual device/account?

2. Whether there's a way to check definitively if a given device has been migrated (e.g. a version suffix like "(26H)", or another indicator)?

3. Whether this AutoSave regression has been linked internally to the Native Sync Engine rollout?

Happy to share more diagnostic details (OneDrive About panel, Finder screenshots, fileproviderctl dump) if useful for triage.

Environment:

- macOS Tahoe 26.7

- OneDrive Standalone 25.243.1211.0001 (Apple Silicon), pinned via script

- Work/school account with synced SharePoint document libraries

Hi all,

is there any update on this issue?

Root cause: the sync root is registered with Office in NFC while the filesystem holds NFD

avallesalas​  is right, and I think it is the cause rather than a contributing factor. I hit this on my own organisation's tenant, then reproduced it deliberately on an unrelated tenant, with a control that differs by exactly one character. Here is the reproduction, the measurement, and the part that surprised me: correcting the plist is not enough.

1. Minimal reproduction — any tenant, any Mac, five minutes

In a SharePoint site where you can create libraries, create two document libraries whose names differ only by an accent:

Documents      (ASCII)
Documentì      (accented)

Same site, same permissions, same File Provider domain, same client, same Mac, same minute. Put a couple of .xlsx in each — files that have never been opened on that Mac — and sync both with the Sync button. Open one file from each library from Finder, and with each workbook open ask Excel what it thinks it has:

osascript -e 'tell application "Microsoft Excel" to get full name of active workbook'

Observed:

Documents   →  https://<tenant>.sharepoint.com/sites/<site>/Documents/s-8.xlsx
Documentì   →  /Users/<user>/Library/CloudStorage/OneDrive-.../<site> - Documentì/7.xlsx

A https:// answer means Office has the cloud identity: AutoSave on, co-authoring works. A /Users/... answer means it does not. Replicated on a second Mac, same account, same result. No client restart is needed for a shared library — the registration is written in the composed form at the first sync.

2. The check, if you want to know whether you are in this case

Read-only, 30 seconds:

python3 - <<'EOF'
import os, plistlib, subprocess, unicodedata
P = os.path.expanduser("~/Library/Group Containers/UBF8T346G9.OfficeOneDriveSyncIntegration/Library/Preferences/UBF8T346G9.OfficeOneDriveSyncIntegration.plist")
d = plistlib.loads(subprocess.run(["defaults", "export", P, "-"], capture_output=True).stdout)
for sid, e in sorted(d["SyncEngineProviders_OneDrive"].items()):
    mp = e.get("MountPoint")
    if not mp:
        continue
    parent, want = os.path.dirname(mp), os.path.basename(mp)
    real = next((v for v in os.listdir(parent) if unicodedata.normalize("NFC", v) == unicodedata.normalize("NFC", want)), None)
    if real is None:
        print("MISSING   ", mp)
        continue
    print("%-10s %s" % ("SAME" if real == want else "DIFFERENT", mp))
    if real != want:
        print("   registry %s" % want.encode().hex(" "))
        print("   disk     %s" % real.encode().hex(" "))
EOF

It compares each registered scope path against the name the directory actually reports, byte for byte, and prints the two byte sequences when they differ.

DIFFERENT on a scope means that scope is affected. SAME everywhere means you have something else, and that matters — see point 6.

3. Caught in the act on a personal OneDrive

I captured the provider registry immediately before and immediately after quitting and relaunching the OneDrive client, changing nothing else, and diffed the two. Excluding timestamps the diff has exactly one entry, and the two lines look identical to the eye:

                      registry    directory on disk    result
  before the restart  NFD cc 80   NFD cc 80            co-authoring WORKS
  after the restart   NFC c3 a0   NFD cc 80            co-authoring DEAD

The correct form is written on the account-setup path and the composed form on every subsequent start. That is why, for a personal OneDrive whose tenant display name carries an accent, this comes back at every login, and why deleting the account's local state and re-adding the account is the only thing that restores it. In my case it held for 2 days and 7 hours — exactly the interval in which the client happened never to be restarted.

4. Correcting the plist is not sufficient — this is the part I did not expect

I rewrote MountPoint and BackingMountPoint with the exact spelling the filesystem reports, resolved component by component, flushed cfprefsd, and fully quit and relaunched Excel so that it re-read the registry. Verified afterwards: registry matches disk byte for byte, and the path Office holds for the document matches the registered MountPoint byte for byte as an exact prefix.

The document is still treated as local. Same outcome on two independent scopes, on two different tenants.

So the comparison that fails is not the one between Office and the plist — the plist entry is a downstream copy. The composed form is throughout the client's own persisted state: SyncEngineDatabase.db, OCSI.db, the account .ini, UXDatabase.db, the whole ListSync tree. A raw byte census over those trees gave me about 1900 composed occurrences against 114 decomposed. Office's own storage, by contrast, is mostly decomposed — which is what you would expect from something that receives its paths from the filesystem.

Please do not spend your afternoon rewriting that plist. I did, twice, and it changes nothing.

5. An objective counter, instead of squinting at the AutoSave toggle

D=$(dirname "$(grep -l <your-tenant-host> ~/Library/Application\ Support/OneDrive/settings/Business*/ClientPolicy.ini | head -1)")
sqlite3 "$D/OCSI.db" "select count(*) tot, coalesce(sum(lastSetPropsResult is not null),0) setprops, datetime(max(lastSetPropsTime),'unixepoch','localtime') last from ocsi_property_records;"

setprops counts the documents for which Office completed the registration handshake. On my two healthy accounts it is in the thousands; on the affected one it stood at 0 out of 2898 tracked documents — the handshake had never once succeeded for that account on that machine.

One trap, and it cost me two days: a document that was registered at some point in the past does not increment the counter. Every measurement has to be made with a file that has never been opened before on that Mac — otherwise you will measure a false negative and conclude you are fine.

6. If you have no accent anywhere — please run the check in point 2 and say so

Several of you report this with no special character in sight, which is why avallesalas hedged. Three possibilities, and they are worth separating before they get merged into one:

• the accent is in the site or library name rather than the tenant name (that is qostech_madion​ 's case, and it is why the language trick doesn't cover it);
• the accent is in the localised OneDrive folder name — which is exactly why Levitas​ ' "switch the OneDrive app to English and restart" works when it works, and why it is unreliable: it only helps where the localised name is the thing carrying the character;
• or you genuinely have a byte-identical registry and are hitting a different defect that happens to share the symptom. If the check prints SAME for every scope and you are still broken, that is a distinct bug and it deserves to be reported as one rather than folded into this.

7. One last thing, for anyone who has been told to reinstall

Windows clients in the same tenants are unaffected — APFS preserves whichever form it was given and decomposes by default, NTFS does not — so this looks like a problem with the individual Mac when it is nothing of the sort. serkantekkesin​  reinstalled macOS and Office over this. If your check in point 2 prints DIFFERENT, no amount of reinstalling will help, and it is worth saying so to support before they send you down that road.

For reference, the matching step is documented behaviour: per the Cloud Storage Partner Program docs, Office "checks if the path of the local file passed in subsumes the path under the third-party mountpoint", and on macOS NSURLIsUbiquitousItemKey returns true if the registered domain "is a subpath of the local file path". A path-prefix test is exactly what two spellings of the same path defeat.

If a couple of you can run the five-minute A/B in point 1 on your own tenants, this stops being a single report.

Marco

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.