Good catch, I overlooked this
You might have overlooked this... but it still SOLVES the issue because a hacker would not get far if he/she found only the cmd window open because the passphrase is needed in order to send NXT this way... as opposed to finding the browser open with an unlocked account where they would freely send NXT without needing the passphrase (at least until a client comes out that will ask for the passphrase again).
Just explaining for the rest... I know you get it!
Then I did misunderstand your original question. Yes, with the cmd window open there appears to be no easy way to s(p)end NXT without knowing the passphrase. Certainly no supported API call.
However, if someone does get SSH access to your server and can login with the unix user that is running the Java process (or root, or a user that can sudo, etc), and you have used the web browser to unlock your account using your passphrase since Java was last restarted (i.e. your are actively trying to forge), then that person can get your passphrase. It's not trivial, but it's not difficult either. I've tested it on a remote instance just now, and it was relatively straightforward. It could probably be scripted to get the passphrase quickly and transparently, and bundled into your favourite trojan/virus/rat/etc.
(I was testing on Linux, but the same would likely apply with remote access to Windows).
So there are interesting questions about where you should forge, what precautions you should take, and with how much of your nxt stash. Don't assume that typing your passphrase over SSL to your VPS is necessarily enough. I don't believe this is purely a client-related topic, so long as the key required to forge is the same as the key required to send/spend nxt. I understand that transparent mining/forging and/or multi-sig (?) may fix this, but I don't know much about those concepts yet.