The issue described involves a scenario where a process, when launched from a root shell initiated by an Android application like Termux, sets its own seccomp filter which inadvertently 'resurrects' all previous filters set by Zygote. This behavior is not observed when the same process is launched from an APatch root shell. The problematic system call in question is setgroups(0,0). An example of a tool that exhibits this behavior is nfqws from the provided GitHub link. When running strace nfqws --qnum 0, a bad system call error is observed. This occurs because the seccomp filter set by nfqws does not filter out the setgroups system call, allowing the process to operate correctly when run from a Magisk root shell. The expected behavior is that once seccomp filters are patched, they should not resurface. However, the actual behavior is that the patched seccomp filters do resurface. Unfortunately, there are no screenshots or logs provided to further diagnose the issue. The device name, OS version, APatch version, kernel version, and KernelPatch version are also not specified, which could be relevant for troubleshooting. Additional context is also missing. This bug could potentially impact system security and stability, as it allows a process to bypass intended security restrictions. Further investigation and possibly a patch to ensure that seccomp filters once applied are permanently enforced, regardless of the process's origin, may be necessary.