Ah apologies, I misread this as you were running the ROOT snap itself; but sure, the problem is specifically regarding the Chromiums snap own usage of temp.
Unfortunately then there likely wonât be any magic, the underlying problem is that to Chromium as a snap, /tmp is actually a different folder, and it wonât find whatever string/filename you provide due to the mount namespace. On the snapcraft side, Iâd made a proposal a while ago that a snap should be able to opt into being able to write into a subdirectory of /tmp that itself is public, because these edge cases are basically unsolvable otherwise, it didnât pick up any traction and annoyingly also wouldnât even help here, because the application would still have to opt into actually using it.
In terms of your options upon rereading then, your fix to move $TMPDIR is basically the only immediate fix. What you might like to do is to use /etc/fstab and make a folder in $HOME that itself is a tmpfs so that itâll always be cleared up like /tmp itself should be. Aside from that, I think youâd need to patch the RBrowser code to prefer somewhere else too.
Since this isnât a problem with the ROOT snap itself, it could be worth raising it as a bug on the Github repo. This likely doesnât even just effect Chromium and e.g., likely doesnât work on the default Ubuntu Firefox - and likely, doesnât even just effect snaps, e.g., Flatpak Browsers could run into similar problems.
As I imagine the underlying problem, the intention is to keep the session token hidden and the file open approach is a good way of achieving that in the usual circumstances, but, with the ecosystem changing around ROOT, maybe having a environment (or build) variable to override this one usage of TMP might be ideal. If ROOT were to e.g., call the XDG Desktop Portals to handle this as would be the current trend in 2025, you technically have some increased risks of e.g., leaking the token to other users or apps on the session bus. On the other hand, most people arenât particularly bothered about leaking secrets to themselves, but in the context of a multiuser machine? Itâs interesting to consider. The downside again, is those portals also donât work everywhere (specifically including WSL2!)