Optional in-memory viewer mode to avoid exposing plaintext to external apps

When you mount a volume, that part is solid. But the moment you open a file with an external app — image viewer, PDF reader, media player — VeraCrypt loses all control over it. That app can cache a thumbnail, write a temp file, add the filename to a recent-files list, or just let the OS page its unlocked memory to swap. None of that is VeraCrypt's fault, but in practice the confidentiality guarantee mostly disappears the moment you actually use the files instead of just mounting the container.

The screen capture protection you added recently protects VeraCrypt's own window, but not whatever app ends up opening the file. Hidden volumes solve a different problem (deniability, not this). Mounting to a RAM disk doesn't help either — external programs reading from it still behave exactly the same way.

What I'm proposing: an optional mode where the user can browse the file list straight from VeraCrypt, and opening a file decrypts it directly into a locked memory buffer shown through small built-in viewers (text, images, PDF) — no external process, no mounted path, nothing for the OS to cache or index. Memory handled the same way you already handle sensitive buffers: locked, zeroed on close, no core dumps while live.

I know this isn't free. Putting image/PDF parsers inside a security-critical process is real attack surface — parser bugs are one of the biggest sources of CVEs in general (libpng, pdfium, etc.). If you ever build this, I'd start small — text, one image format, basic PDF — and honestly the parsing should probably run in a separate sandboxed process talking to the core over a narrow channel, not inside the privileged code. Video/audio without ever touching disk is genuinely hard cross-platform (decoders usually want a real file handle), so I'd leave that out of a first version entirely.

This wouldn't replace mount-as-drive, which is still needed for anything that does real file I/O. It's for the specific case of looking at a handful of sensitive files without ever handing them to anything outside VeraCrypt.

I built a working proof of concept doing this end-to-end (Python, not proposing the code itself gets used, just showing it's doable): double-layer AES-GCM+CBC container kept fully in RAM, locked/zeroed memory, built-in viewers for images/PDF/text/audio/video, screen capture protection on every window. Repo: https://github.com/zmykerd/bcypherpy

Before I spend time on an actual design doc scoped to your codebase — is this a direction you'd consider, or is the sandboxing requirement a dealbreaker for maintenance reasons?