I’m not personally familiar with cipher.exe, but based on a quick scan of the info on this page, it seems that this tool may be applicable only if your system uses EFS, and also, that it erases your entire disk (not just a folder). Furthermore, as the cipher.exe tool evidently dates back to 2001, it is unclear whether it is designed to work with SSDs.
If you are using an SSD, it is difficult/impossible to overwrite a specific block of the drive, because wear-leveling and over-provisioning processes will just shift the data around to other blocks. On the other hand, if you trust that the drive controller’s TRIM function is correctly implemented and that no unauthorized drive access will occur before the TRIM operations are scheduled, then you may not need to take any extra action to eliminate traces of deleted data.
Furthermore, if your system already uses whole-disk encryption (e.g., using Bitlocker or VeraCrypt), then the risks associated with deleted data are significantly reduced.
Please modify the vault export feature to allow a user to select a location to store the file prior to export. This would allow the user to send the export directly to an encrypted storage service like Microsoft OneDrive Personal Vault. This would then bypass the file ever being at rest in an unencrypted storage like a file folder on a laptop.
I cannot tell whether or not you are using a browser extension or not. If you are using a browser such as FireFox, etc… you can designate a location for all downloads and thereby direct the download to a specific folder. I do this and direct my exports to a virtual drive. That would solve what I think you are looking for. I happen to use a virtual machine so I blow away all OS tracks via restoring a snapshot as well.
Likely the easiest solution is to use the encrypted export feature so that no plain text export ever even gets to your machine. You should see that option in the BW Vault when you click to export.
The windows desktop app does allow one to specify a folder to save the export. Unfortunately, it does not prevent the file from being temporarily written to the downloads folder. Apparently, this is a limitation of the development environment. See this conversation for details. Given that apps are being rewritten (slowly) to be “native”, this may change at some point, but who knows for sure.
In the meantime, perform a password-encrypted JSON export to eliminate the transient risk. You can use the same password for all your exports. It should be written both on your emergency sheet incase you need it to recover, and it can be kept in your vault for easier exports. Presuming a long, unique and random password/phase, this can eliminate the need to securely store the export itself, although there is no harm in doing so.
Password-protected exports can be imported back into a newly created Bitwarden vault, can be imported into KeepassXC (a competitor) and there are some (perhaps outdated) github scripts that can remove the password if it proves necessary.