Testing on 10.15.5, sandbox violations don't appear in syslog files and this code is not capturing violations when its enabled.

Violations do show up in log stream --debug --info when violation logging is enabled (security.sandbox.logging=true) which might mean there is another method to programmatically access the violations from Firefox.

It's possible you've run up against an Apple bug that I've seen using printf() and kprintf() in kernel extensions on macOS 10.15.4 and 10.15.5: If your "message" is longer than 242 characters (including the newline and terminal NULL), it gets suppressed (at least in the Console app). You don't see anything at all.

Apple should really just truncate a message that's too long.

@Steven, I retested this and haven't been able to get nsSandboxViolationSink to log any violations on 10.16. Are you able to verify if it's still possible to access the logged violations this way?

What I said in comment 3 doesn't come from testing with any kind of violation message. Rather, working on a new kernel extension, I discovered that (as of macOS 10.15.4, at least) there's now a hard limit on the length of any "message" you log from a kernel extension (using printf() or kprintf()). Logging violation messages may somehow involve the kernel, so I wondered if the same limit might apply to them.

Are any of the messages you're trying (and failing) to log less than 242 characters long? If so, then you're seeing some other kind of problem, and my comment was irrelevant.

It now occurs to me that you aren't trying to log sandbox violation messages, but to capture them. My comment 3 might still be relevant, but only if the messages that you're trying (and failing) to capture are greater than 242 characters long.