Yes. Every lock entry point (manual, auto-lock timer, app shutdown) funnels through one function, so the behavior can't drift, that calls lock_for_lifecycle, which drops the unlocked session. Dropping UnlockedVault zeroizes the 32-byte vault key and the whole in-memory payload in place before deallocation: names, logins, notes, cards, SSH keys, TOTP material, history, trash. Parsed import rows are wiped on lock too, and a session epoch is bumped so any pending browser fill approval dies with the lock! (also to mention it does not cover swap and hibernation files) ((also to mention I couldn't link the lines to mentioned functions but if you want to take a look, look at these lines: src-tauri/src/vault/mod.rs:78 sesame-core/src/lib.rs:197 sesame-core/src/lib.rs:225 types.rs:2184 ))
Yes. Every lock entry point (manual, auto-lock timer, app shutdown) funnels through one function, so the behavior can't drift, that calls lock_for_lifecycle, which drops the unlocked session. Dropping UnlockedVault zeroizes the 32-byte vault key and the whole in-memory payload in place before deallocation: names, logins, notes, cards, SSH keys, TOTP material, history, trash. Parsed import rows are wiped on lock too, and a session epoch is bumped so any pending browser fill approval dies with the lock! (also to mention it does not cover swap and hibernation files) ((also to mention I couldn't link the lines to mentioned functions but if you want to take a look, look at these lines: src-tauri/src/vault/mod.rs:78 sesame-core/src/lib.rs:197 sesame-core/src/lib.rs:225 types.rs:2184 ))