Hi Kevin, thank you for getting back to us. So, looking at things from our side, I'm not sure. I found one bug on this (r.166518515) about accessing a custom directory ("/Library//"), but the analysis of the engineering team is that it isn't a bug in macOS 26.2... because it shouldn't work in macOS 26.0 EITHER. We have read the man page, and it refers to default sandbox-on behaviour, and not the sandbox-relaxed mode (which we moved to starting from 10.10). As you mentioned, the sandbox-on mode works as advertised in 26.0+. The sandbox-relaxed mode works up to 26.1 and stopped working in 26.2. FYI, that does suggest a possible workaround for these issues, which would be to: Have your CUPS component write to an allowed directory (for example, /Library/Application Support/). If necessary, create a symlink to that location at your current location so that the user-visible behavior remains the same. We are actively working to support sandbox-on mode. However, this is non-trivial for reasons such as: File and folder access: other parts of our product are expecting files to be in specific locations, and we need to create symlinks back from those locations. Some of these files are log files, which involve log rotation, making things more complex. Execute/kill sub-processes: we can no longer kill sub-processes spawned by the backend. We get an EPERM error Network calls from filters: these are no longer possible In the interim: Is there anything we can configure or modify in the system to achieve the old behaviour of sandbox-relaxed mode? If for some reason, we can’t get back to the previous sandbox-relaxed behaviour, is there a way for us to switch off the sandbox? As of now, we are looking for a quick fix, as we have 100,000s of macOS users who will be unable to print once they upgrade to Tahoe 26.2.

Hi Kevin, Thank you for the clarification. However, we want to emphasize that the decision to have cupsd ignore one of its main configuration files is a major breaking change. This is not just a tightening of the sandbox but a major departure from documented CUPS behavior (https://www.cups.org/doc/man-cups-files.conf.html). By ignoring cups-files.conf, macOS disables essential administrative controls required for non-standard printing environments. As such, we hope the team will reconsider this approach. If a fixed configuration is necessary for the default security posture, there should still be an alternative that allows legitimate, authorized software to operate in “relaxed” mode. In terms of supporting CUPSD_SANDBOXING_STRICT, am I correct that these two points are the real issues here, not the path limitations? As we mentioned earlier, it is a combination of all three (file/folder access, sub-process handling, and network calls). We are actively working on modifying our backend/filter to accommodate these restrictions and operate in CUPSD_SANDBOXING_STRICT mode, which requires a careful rewrite of the code to ensure that we don't break current behavior and cause issues for users.