Excel Copilot fails when local workbook filename contains #

You’ve spotted a really interesting pattern! It’s totally understandable that you’d be confused—the error message is misleading, and the behavior definitely looks like a bug at first glance. Let me walk you through what's happening and, more importantly, how to get Copilot working smoothly for you.

Microsoft recommends using Copilot in Excel with files saved to OneDrive or SharePoint and AutoSave turned on, because that is where Copilot provides its most complete experience. However, local .xlsx files can also work with Copilot, so the fact that your file works after removing # strongly suggests a filename-parsing bug rather than an unsupported file type.

So why does the # character cause trouble locally?

Think of the # like a bookmark in a web address—it tells your browser to jump to a specific spot on a page. When Copilot looks at your local file path (for example, C:\Reports\Report #1.xlsx), it gets confused and treats everything after the # as a web bookmark instead of part of the actual filename. That breaks the path, so Copilot can't "find" your file properly and throws that confusing "unsupported file type" message.

Other symbols like % or & don't have this special "bookmark" meaning, which is why they work just fine.

Your best, most reliable solution

Since cloud storage gives Copilot the smoothest experience, your safest option is to save or move your workbook to OneDrive or SharePoint. Once it's there, just make sure AutoSave is switched on. When you open it from the cloud, Copilot should work perfectly—even if the # stays in the filename.

If you need to keep the file on your computer

You can simply rename the file to remove the #—for example, change Report #1.xlsx to Report - 1.xlsx or Report_1.xlsx. As you've already seen, this makes Copilot work again. Since this is a bug in the filename handling, renaming is a solid workaround that should keep working for you.

Should you report it to Microsoft?

Yes, please do! Your observation is valuable because it isolates the problem so precisely. You can go to Excel > Help > Feedback > Report a problem and share what you found. Mention that the same .xlsx file works locally without the #, works on OneDrive with the #, and that the error message is misleading. That kind of clear, reproducible case is exactly what helps Microsoft engineers track down and fix bugs.

My answers are voluntary and without guarantee!

Hope this will help you.