The problem described here is not a bug report, it is a warning sign. When a macro that has worked reliably for every user on every machine suddenly fails for one person, then a second, then a third on separate hardware, the issue has moved beyond code. The pattern points to something deeper in the environment, and the fact that a clean login on a different machine resolves it tells us the fault lies not in the spreadsheet but in the user profile and the directory services that sustain it.
What this means in practical terms is that organizations relying on macros to open workbooks via hyperlinks and then immediately act on those workbooks are now facing a failure mode that is intermittent, profile-dependent, and almost impossible to reproduce on demand. The macro itself is not broken. It does exactly what it was written to do: follow the hyperlink, open the file, select the sheet. But the macro cannot see what it has opened because, from the perspective of the running instance, the new workbook does not exist. That is not a logic error. That is a visibility problem introduced somewhere between the user's credentials, the Active Directory policies applied to that profile, and the way Microsoft 365 handles file-handle permissions for macro-triggered actions.
The most troubling detail is that recreating the profile worked for a week and then failed again. That suggests a policy or a background service is reapplying a configuration that breaks the macro's ability to recognize the newly opened workbook. User2 inheriting the issue on the same machine points to a machine-level policy or a cached credential corruption that survives profile deletion. User3 getting the same error on a separate machine confirms this is not hardware-specific. It is environmental and it is spreading.
Our take is straightforward: this is not a macro problem you can fix by rewriting VBA code. The macro works everywhere else. The fix lives in the identity and permissions layer, specifically, how Microsoft 365 handles file visibility across processes when a macro opens a workbook programmatically. You should audit recent Active Directory changes, check for Group Policy updates that affect file-handle inheritance or inter-process communication, and verify whether the affected users share a security group or license tier that differs from unaffected users. The clean-login workaround is a temporary bridge, not a solution. Until the root cause is identified and reversed, every new user who logs into those machines is a potential carrier.