You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Repeatedly getting the “Welcome, first use please: …” prompt #861
I've seen this welcome message about five times since I started using Userscripts:
Welcome, first use please: Open Userscripts App
to complete the initialization
My guess is that it appears after each app update. This shouldn't be necessary, since the app should retain its settings data between updates. It feels like a bug.
Reacted by seNqejnicru5, Johnny Quidd and MotherOfClamperl
Same here, on iPadOS 18.
Scripts folder is in iCloud Drive, keep downloaded folder enabled. Userscripts.app loose path to this folder, need to re-select it manually, sometimes several times a day. And sometimes display wrong version number -see picture
@sushione The new build does not make any changes to this issue.
Maybe you can add a button with "use same previous folder" so it can be set quickly for example ?
Thanks for the suggestion, but I think any simple changes at the moment will make things more confusing than simple, when we face thousands of users.
It is an upstream bug, but for the user it is reflected as an issue of the App (Extension).
When App/Extension cannot read the iCloud directory set by the user due to this upstream error, we must go through some kind of interrupt:
If we don't reset the directory, it will manifest as sometimes the extension cannot be successfully injected into the scripts and are hard to detect.
If we add a button without explaining it, the user will be confused about it, is it the expected behavior? Why should I use the button regularly?
Since this error usually occurs in the automatic injection process, i.e. when the user does not interact with the popup or the app, we cannot directly display the error.
So we need to implement some kind of catching and recording mechanism to show errors or reset reasons the next time the user opens App/Extension. This will be a complex user interface and background logic reconstruction.
To truly solve this issue, we need to implement #817 so that we don't cause interruptions due to this upstream error. But this will be a complex background logic and injection process reconstruction.
The best way to avoid this issue at present is to use a local directory instead of an iCloud directory if you frequently encounter this upstream error.
Maybe you can add a button with "use same previous folder" so it can be set quickly for example ?
@sushione Sorry, I forgot to mention that this is also impossible because we cannot access "previous folder" if we can't resolve the bookmark.
In order to obtain access to the path outside the app sandbox, we must call the system's document Picker to obtain access to the directory selected by the user.
This is also the reason why this logic exists in the initially, that is, if the path outside the sandbox is unreachable (for example, the path is deleted by user), we can only reset it to the document path inside the sandbox.
I've encountered this issue multiple times as well. My current save location is a local folder under 'On My iPhone' in the Files app, not iCloud Drive. I haven't experienced this issue on my Mac, only on my iPad and iPhone.
I am experiencing the same as @Flickering-Allies-0771 on iPad. I use On My iPad -> Userscripts (the default). I have to open the app, click "Change Userscripts Directory", then hit open, and my scripts will load again. Sometimes only a few hours pass and I have to do it all over again.
No, the folder is not belonging to another app; it is the app's own folder and has the Userscripts app icon on it.
For further confirmation. In other words, you have not changed the directory, you just opened the App and displayed "Userscripts App Documents", right?
Thanks, I checked your logs initially and it looks like the same error as before:
I didn't expect the issue to occur in a local or even default directory as well. This is even worse.
This is an issue with Apple's API, it seems to happen frequently only in some specific devices, I can't simply fix the issue since it prevents everything else from working.
But I'm refactoring the entire workflow to cache content to an internal App directory to reduce the impact of this issue. And provide better error prompts and stop resetting the directory.
In fact, some users have reported similar issues recently, which may be caused by a bug introduced by Apple in a recent versions.
Since the first failure of resolvBookmark will clear the bookmark, subsequent users must open the app and re-initialize the directory, which causes user frustration.
After quick thought, maybe as a quick mitigation, I could first stop remove bookmarks because of that failed call, if it's actually just sporadic.
This reduces user interaction requirements and frustration
But it will also silently hide the occurrence of the error
For example, scripts cannot be injected while browsing sometimes
But as a quick temporary mitigation, it should still help users before the refactoring is complete.
For further confirmation. In other words, you have not changed the directory, you just opened the App and displayed "Userscripts App Documents", right?
Right—I didn't change the directory. I opened the app and it showed "Userscripts App Documents."
After quick thought, maybe as a quick mitigation, I could first stop remove bookmarks because of that failed call
Would it be possible to hard-code the default directory ("Userscripts App Documents") and use that when the bookmark fails to resolve?
Right—I didn't change the directory. I opened the app and it showed "Userscripts App Documents."
Thanks, that's really bad, but it's not a bug from the project, it's Apple's bug.
Would it be possible to hard-code the default directory ("Userscripts App Documents") and use that when the bookmark fails to resolve?
No, that default directory is itself that bookmark, we can't hardcode it.
Since Extension and App are actually two different "packages", we have to go through the secure bookmark to access that directory.
The bookmark is created when you first open the App, and then the extension uses this bookmark to read the directory content.
However, the Apple API returned this error when the extension parsed the bookmark at a certain time. The extension thought the bookmark was invalid and deleted it.
At this time, you can only re-create the bookmark by opening the App again, there is no other way.
The directory of the extension itself cannot be exposed to the Files App. Only the document directory of the App itself can be displayed in Files. This is why we use this directory by default.
Thank you. I'll try the latest beta version and keep you updated on the results.
it only occurs on specific devices
I don’t think it’s just specific devices, as I experience the bug on both my iPhone and iPad. It seems to happen randomly, and I have no reliable way to reproduce it other than waiting a few days until it occurs again.
To be honest, I don't know the extent of the impact. Given the limited feedback we've received so far, I can only assume it's affecting certain devices/systems.
Furthermore, it seems to have only started appearing in the last few months, and I don't know the range of system versions affected.
Furthermore, based on the available information, a "helper application" should typically be used with iCloud or third-party cloud storage file providers. I don't know why it also affects local folders.
as I experience the bug on both my iPhone and iPad
When your devices are logged into the same account, it's not so surprising that sometimes errors can "spread".
and I have no reliable way to reproduce it other than waiting a few days until it occurs again.
The same applies to me; I can only try to mitigate and fix the issues based on the error logs reported by everyone.
Hopefully, it's just an occasional, recoverable error, and the mitigation measures will be effective.
I tried the latest beta and the fix works. The error still occurs but appears to recover on its own.
I searched the logs for faild resolv bookmark, return default and found one occurrence:
2025-12-0923:10:38+0000ErrorUserscripts-iOS-Safari-Extensioncom.userscripts.macos.Userscripts-ExtensionUserscripts_iOS_Safari_Extension/Preferences.swiftresolvBookmark(_:_:)-ErrorDomain=NSCocoaErrorDomainCode=4099"The connection to service named com.apple.FileProvider was invalidated from this process."UserInfo={NSDebugDescription=Theconnectiontoservicenamedcom.apple.FileProviderwasinvalidatedfromthisprocess.}2025-12-0923:10:38+0000ErrorUserscripts-iOS-Safari-Extensioncom.userscripts.macos.Userscripts-ExtensionUserscripts_iOS_Safari_Extension/Preferences.swiftwrappedValue-faildresolvbookmark,returndefault2025-12-0923:10:38+0000InfoUserscripts-iOS-Safari-Extensioncom.userscripts.macos.Userscripts-ExtensionUserscripts_iOS_Safari_Extension/Utilities.swiftgetSaveLocation()-Uninitializedsavelocation
I've forward-ported the fix to App Store version v4.8.3 / v1.8.3.
This upstream issue should be effectively mitigated. But it may still happen, for example, just when the user opens the extension interface. This situation will be fully taken into account in subsequent reconstruction.
I guess it is a bug related to the context management of the foreground App switching.
And the reason for the error always seems to be that the com.apple.FileProvider is not responding properly, whether it is suddenly interrupted or not restored? I don't know, but it seems to be a bug introduced by Apple in recent months.
2025-12-0923:10:38+0000NoticeUserscripts-iOS-Safari-Extensioncom.apple.xpcconnection[0x1058fc500]Re-initializationsuccessful;callingouttoeventhandlerwithXPC_ERROR_CONNECTION_INTERRUPTED2025-12-0923:10:38+0000InfoUserscripts-iOS-Safari-Extensioncom.apple.FileProviderdefault[INFO]FPDaemonConnectioninterrupted2025-12-0923:10:38+0000NoticeUserscripts-iOS-Safari-Extensioncom.apple.xpcconnection[0x1058fc500]invalidatedbecausethecurrentprocesscancelledtheconnectionbycallingxpc_connection_cancel()2025-12-0923:10:38+0000InfoUserscripts-iOS-Safari-Extensioncom.apple.FileProviderdefault[INFO]FPDaemonConnectioninvalidated.---2025-12-1103:35:15+0000InfoUserscripts-iOS-Appfailedtoconsumesandboxextension: [22: Invalidargument]2025-12-1103:35:15+0000InfoUserscripts-iOS-Appcom.apple.FileProviderdefault[INFO]LoadedmoduleICDFileProviderFrameworkOverridefrombundlecom.apple.icloud.drive.fileprovider.override2025-12-1103:35:15+0000InfoUserscripts-iOS-Appcom.apple.FileProviderdefault[INFO]LoadedmoduleFPFileProviderModulefrombundlecom.apple.FileProviderOverride2025-12-1103:35:15+0000InfoUserscripts-iOS-Appcom.apple.FileProviderdefault[INFO]Loaded2frameworkoverridesmodules.2025-12-1103:35:15+0000InfoUserscripts-iOS-Appcom.apple.FileProviderdefault[INFO]CreatingnewFPDaemonConnectionconnection.2025-12-1103:35:15+0000NoticeUserscripts-iOS-Appcom.apple.xpcconnection[0x10a099040]activatingconnection: mach=truelistener=falsepeer=falsename=com.apple.FileProvider2025-12-1103:35:15+0000ErrorUserscripts-iOS-Appcom.userscripts.macosUserscripts_iOS_App/Preferences.swiftresolvBookmark(_:_:)-ErrorDomain=NSCocoaErrorDomainCode=4097"connection to service named com.apple.FileProviderResolver.Service"UserInfo={NSDebugDescription=connectiontoservicenamedcom.apple.FileProviderResolver.Service}
I will continue to study these logs and thank you again for providing them!
Activity
ACTCD commentedon Aug 26, 2025
No, updating the app will not reset it.
The message appears because
save locationis not initialized.Most likely you set a iCloud directory as
save location, and because the directory is evicted by the OS, the path is inaccessible and reset.So, did you:
save location?Reference:
sushione commentedon Aug 28, 2025
Same here, on iPadOS 18.
Scripts folder is in iCloud Drive, keep downloaded folder enabled. Userscripts.app loose path to this folder, need to re-select it manually, sometimes several times a day. And sometimes display wrong version number -see picture
ACTCD commentedon Aug 29, 2025
@sushione I cannot reproduce the issue, and none of the previous several similar issues provide relevant logs to determine the issue.
Without a log, I really can't determine the real cause of the error, I can only rely on the logic of the code to speculate.
So it will be of great help if you could collect and provide relevant logs.
Install the beta app and refer to the following issues and video export logs:
The issue with version number 0.0.0 should have been fixed, but also only in beta:
seNqejnicru5 commentedon Aug 29, 2025
Just want to report I start to get this exact bug these few days. And I have set the directory in a local folder.
ACTCD commentedon Aug 29, 2025
@19X17 Please try to gather logs to help locate the issue.
@everyone, please include at least your OS version and App version to help locking possible bugs in specific range of the system.Thank you.
sushione commentedon Aug 30, 2025
Lost path again today, using uptodate iPadOS (18.6.2) and latest testflight release (5.0.0beta16 c729099). Logs included
com.userscripts.macos.Userscripts-Extension.log
com.userscripts.macos.log
ACTCD commentedon Aug 30, 2025
@sushione Thanks very much for providing the logs, which gives us the first time we see the related error log:
Impossible de communiquer avec une application d’aide.corresponding English message should beCouldn't Communicate with a helper application..According to some quick search, the error should be related to iCloud File Provider.
We cannot resolve the error itself, it needs to be resolved by Apple.
But we will have the opportunity to better catch and handle the error.
I think what we could do at the moment is:
Implementing these will take a lot of time, and the current recommendation is to use a local folder rather than iCloud Drive.
sushione commentedon Aug 30, 2025
Thanks, will test with new build.
Maybe you can add a button with "use same previous folder" so it can be set quickly for example ?
ACTCD commentedon Aug 30, 2025
@sushione The new build does not make any changes to this issue.
Thanks for the suggestion, but I think any simple changes at the moment will make things more confusing than simple, when we face thousands of users.
It is an upstream bug, but for the user it is reflected as an issue of the App (Extension).
When App/Extension cannot read the iCloud directory set by the user due to this upstream error, we must go through some kind of interrupt:
So we need to implement some kind of catching and recording mechanism to show errors or reset reasons the next time the user opens App/Extension. This will be a complex user interface and background logic reconstruction.
To truly solve this issue, we need to implement #817 so that we don't cause interruptions due to this upstream error. But this will be a complex background logic and injection process reconstruction.
The best way to avoid this issue at present is to use a local directory instead of an iCloud directory if you frequently encounter this upstream error.
ACTCD commentedon Aug 30, 2025
@sushione Sorry, I forgot to mention that this is also impossible because we cannot access "previous folder" if we can't resolve the bookmark.
In order to obtain access to the path outside the app sandbox, we must call the system's document Picker to obtain access to the directory selected by the user.
This is also the reason why this logic exists in the initially, that is, if the path outside the sandbox is unreachable (for example, the path is deleted by user), we can only reset it to the document path inside the sandbox.
Flickering-Allies-0771 commentedon Nov 20, 2025
I've encountered this issue multiple times as well. My current save location is a local folder under 'On My iPhone' in the Files app, not iCloud Drive. I haven't experienced this issue on my Mac, only on my iPad and iPhone.
ACTCD commentedon Nov 21, 2025
@Flickering-Allies-0771 It would be best to provide error logs to help identify the exact cause.
Is it a folder belonging to another app?
MotherOfClamperl commentedon Nov 25, 2025
I am experiencing the same as @Flickering-Allies-0771 on iPad. I use On My iPad -> Userscripts (the default). I have to open the app, click "Change Userscripts Directory", then hit open, and my scripts will load again. Sometimes only a few hours pass and I have to do it all over again.
screenshot
ACTCD commentedon Nov 25, 2025
@MotherOfClamperl Does this happen even with the default "App Documents" directory?
Could you please collect some logs with reference to the comment above?
Flickering-Allies-0771 commentedon Nov 28, 2025
@ACTCD Here are the error logs you requested.
com.userscripts.macos.log
com.userscripts.macos.Userscripts-Extension.log
No, the folder is not belonging to another app; it is the app's own folder and has the Userscripts app icon on it.
ACTCD commentedon Nov 28, 2025
@Flickering-Allies-0771
For further confirmation. In other words, you have not changed the directory, you just opened the App and displayed "Userscripts App Documents", right?
Thanks, I checked your logs initially and it looks like the same error as before:
Couldn’t communicate with a helper application.I didn't expect the issue to occur in a local or even default directory as well. This is even worse.
This is an issue with Apple's API, it seems to happen frequently only in some specific devices, I can't simply fix the issue since it prevents everything else from working.
But I'm refactoring the entire workflow to cache content to an internal App directory to reduce the impact of this issue. And provide better error prompts and stop resetting the directory.
ACTCD commentedon Nov 28, 2025
In fact, some users have reported similar issues recently, which may be caused by a bug introduced by Apple in a recent versions.
Since the first failure of
resolvBookmarkwill clear the bookmark, subsequent users must open the app and re-initialize the directory, which causes user frustration.After quick thought, maybe as a quick mitigation, I could first stop remove bookmarks because of that failed call, if it's actually just sporadic.
But as a quick temporary mitigation, it should still help users before the refactoring is complete.
Flickering-Allies-0771 commentedon Nov 29, 2025
@ACTCD
Right—I didn't change the directory. I opened the app and it showed "Userscripts App Documents."
Would it be possible to hard-code the default directory ("Userscripts App Documents") and use that when the bookmark fails to resolve?
ACTCD commentedon Nov 29, 2025
Thanks, that's really bad, but it's not a bug from the project, it's Apple's bug.
No, that default directory is itself that bookmark, we can't hardcode it.
Since Extension and App are actually two different "packages", we have to go through the secure bookmark to access that directory.
The bookmark is created when you first open the App, and then the extension uses this bookmark to read the directory content.
However, the Apple API returned this error when the extension parsed the bookmark at a certain time. The extension thought the bookmark was invalid and deleted it.
At this time, you can only re-create the bookmark by opening the App again, there is no other way.
The directory of the extension itself cannot be exposed to the Files App. Only the document directory of the App itself can be displayed in Files. This is why we use this directory by default.
ACTCD commentedon Nov 29, 2025
Please try the latest beta version. https://github.com/quoid/userscripts/releases/tag/v5.0.0-beta.20
If it's just an occasional bug and recoverable, then the fix should work.
Please let me know your test results; it will help we decide whether to push the fix to App Store users.
Because it only occurs on specific devices, I am unable to reproduce and test the bug.
If you still encounter the bug, please continue to submit logs so that we can observe the error patterns and processes.
Flickering-Allies-0771 commentedon Nov 29, 2025
Thank you. I'll try the latest beta version and keep you updated on the results.
I don’t think it’s just specific devices, as I experience the bug on both my iPhone and iPad. It seems to happen randomly, and I have no reliable way to reproduce it other than waiting a few days until it occurs again.
ACTCD commentedon Nov 29, 2025
To be honest, I don't know the extent of the impact. Given the limited feedback we've received so far, I can only assume it's affecting certain devices/systems.
Furthermore, it seems to have only started appearing in the last few months, and I don't know the range of system versions affected.
Furthermore, based on the available information, a "helper application" should typically be used with iCloud or third-party cloud storage file providers. I don't know why it also affects local folders.
When your devices are logged into the same account, it's not so surprising that sometimes errors can "spread".
The same applies to me; I can only try to mitigate and fix the issues based on the error logs reported by everyone.
Hopefully, it's just an occasional, recoverable error, and the mitigation measures will be effective.
Flickering-Allies-0771 commentedon Dec 11, 2025
@ACTCD
I tried the latest beta and the fix works. The error still occurs but appears to recover on its own.
I searched the logs for
faild resolv bookmark, return defaultand found one occurrence:Here are the full logs:
com.userscripts.macos.log
com.userscripts.macos.Userscripts-Extension.log
ACTCD commentedon Dec 11, 2025
@Flickering-Allies-0771 Thanks much, this information is very helpful!
I've forward-ported the fix to App Store version v4.8.3 / v1.8.3.
This upstream issue should be effectively mitigated. But it may still happen, for example, just when the user opens the extension interface. This situation will be fully taken into account in subsequent reconstruction.
I guess it is a bug related to the context management of the foreground App switching.
And the reason for the error always seems to be that the
com.apple.FileProvideris not responding properly, whether it is suddenly interrupted or not restored? I don't know, but it seems to be a bug introduced by Apple in recent months.I will continue to study these logs and thank you again for providing them!