Why is there severe save latency in Microsoft Office for macOS due to macOS com.apple.macl extended ?attribute

Summary

Office apps on macOS (Excel, Word, PowerPoint) exhibit severe save delays—up to 10-15 seconds—once an affected document acquires the com.apple.macl extended attribute. New files save instantly, but after some time or specific events, the same files begin to save slowly. Copying the file with cp -X (removing extended attributes) immediately restores normal performance.

This behavior strongly indicates that Office’s sandbox interacts poorly with macOS’s mandatory-access-control (MACL) enforcement, causing redundant authorization or metadata checks on every save.

Environment

• MacBook Pro M1
• macOS Tahoe 26.01
• Microsoft 365 for Mac (Excel, Word) -- latest installer

Steps to Reproduce

1. Create a new Excel or Word document in any user-writable location (e.g., Desktop).
2. Confirm the file has no com.apple.macl: xattr -l file.xlsx
3. Work in the file for some time, or trigger autosave/backup/sync (e.g., use OneDrive/Google Drive or move the file around).
4. Eventually, the file gains a com.apple.macl attribute. ls -le@
5. Attempt to save; observe 15 second spinner (“Saving…”).
6. Copy the file using cp -X file.xlsx file2.xlsx and reopen file2.xlsx → saves instantly. New file has no com.apple.macl attribute as seen by ls -le@

Expected Behavior

Save operations complete in under one second regardless of macOS extended attributes.

Actual Behavior

Once com.apple.macl is present, each save triggers long blocking calls (visible in sample output as WaitForSingleObjectEx and _pthread_cond_wait), consistent with repeated sandbox/MACL validation by macOS security services.

Technical Evidence

ls -l@ shows slow files carry com.apple.macl; identical fast files do not.

fs_usage reveals multiple metadata (fstat, fcntl, renamex_np) stalls, no disk I/O contention.

sample "Microsoft Excel" captures the main thread blocked inside Office’s save pipeline while macOS performs security callbacks.

Removing extended attributes (cp -X or rsync --no-xattrs) clears the issue.

Request

Please investigate how Office’s sandboxed save process interacts with macOS files that carry com.apple.macl. Specifically:

• Avoid or minimize redundant MACL/TCC authorization checks on each save.
• Prevent Office from re-tagging files unnecessarily.
• Document the relationship between AutoRecover, sandbox helpers, and extended attributes.

A fix that stops Office from introducing or re-validating com.apple.macl on normal user files would eliminate this persistent performance issue.

Additional Technical Information

1.Identify Excel Save Stall

log show --predicate 'process == "Microsoft Excel"' --last 5m

Revealed long gaps between sendAction: and flushAllChanges, indicating Excel blocked during save.

sudo sample "Microsoft Excel" 10 -file excel_sample.txt

Showed main thread stuck in WaitForSingleObjectEx, confirming Excel’s own save thread waiting on OS security or sandbox I/O.

2. Trace File I/O

sudo fs_usage -w -f filesystem "Microsoft Excel"

Showed normal open, pwrite, fsync patterns—no external lock contention—ruling out disk or sync causes.

3. Check for External Locks

sudo lsof | grep broken.xlsx

No other process held the file.

4. Inspect Attributes and ACLs

ls -l@ broken.xlsx
xattr -l broken.xlsx

Found com.apple.macl present only on slow files.

ls -le confirmed an invisible ACL entry.

Copying with:

cp -X broken.xlsx new.xlsx

removed extended attributes → file saved instantly.

Finding: com.apple.macl extended attribute directly correlates with slow saves.