Note: First of all, let me clarify that if a machine on which a password manager is running is compromised, no amount of memory protection or other safeguards will completely save the user (and a compromised computer is also not the threat a password manager is designed to defend against). That said, a password manager can take measures to limit the damage in some situations.
The following techniques are only useful in case of infection by unprivileged malware (you cannot defend against malware with root/admin privileges), and will protect only those secrets that do not leave the password manager. Passwords that are used will be compromised while being entered into the browser. However, any passwords that haven't been used won't, nor any TOTP secrets (if the password manager includes TOTP support).
Here are some things you can take care of:
The password manager's memory shouldn't be unnecessarily accessible by other processes
By default, processes can access the memory of other processes that are running with the same (or less) privileges under the same user. This means that even unprivileged malware can extract the master key or other secrets from memory. sodium_mprotect_noaccess() will not save you here, since malware can also change the memory protection flags on another process's memory.
Some password managers try to overcome this by encrypting secrets in memory. This amounts to security by obscurity and has very limited benefit. Instead, you should protect memory like KeePassXC does, making it inaccessible to all other unprivileged processes. (You'll probably have to look at the source code to figure out how they implement this. If memory serves me right, on Windows they do it using DACLs.)
Protect the master password
Apart from memory protection, you want to protect the master password from being key logged, otherwise the entire password database will be compromised to the point that all other protections will be useless.
One way you can reduce the chances of the master password being key logged (on Windows only, I do not know if the equivalent can be done on Linux/MacOS) is the use of what some password managers like to call 'secure desktop' (not the same thing as the Secure Desktop that Windows uses for login and UAC prompts). Basically, the main password manager process creates a new desktop using CreateDesktop, prompts the user to enter the master password on the new desktop, closes the desktop and returns to the main desktop (check KeePass's source for implementation details). Any process running on the main desktop cannot directly key log the master password on the new desktop.
Although this will mitigate common keyloggers, any malware that is aware of this technique can enumerate all desktops and create a process on any new desktops, allowing it to key log the master password[1]. The solution is to check the new desktop for any unauthorized processes, and either kill them or prompt the user about them
