Nice. That need was one of my initial inspirations for AQ as well. The VPS plus dropped-connections part of your story is very familiar. Two things mattered most when I worked on this same problem:
first, persistence has to live server-side (tmux or equivalent), so the browser tab is only a view and never the owner of the session; if the tab dying can kill work, mobile use stays fragile.
Second, on your security question: the relay path sees every keystroke and whatever secrets scroll through the terminal, so I'd frame it as custody rather than transport. Keep credentials only on the executing machine, make any shareable view a short-lived, token-scoped link with an explicit revoke, and treat Tailscale-first as the default rather than the fallback.
Disclosure: I'm building AQ (aq.dev), which lives in this same problem space (agent sessions that keep running after you close the laptop, joinable from a browser), so I've spent a lot of time on exactly these two questions. We compared the options, including the plain VM plus tmux route, here: https://aq.dev/guides/keep-claude-code-running-after-closing...
first, persistence has to live server-side (tmux or equivalent), so the browser tab is only a view and never the owner of the session; if the tab dying can kill work, mobile use stays fragile.
Second, on your security question: the relay path sees every keystroke and whatever secrets scroll through the terminal, so I'd frame it as custody rather than transport. Keep credentials only on the executing machine, make any shareable view a short-lived, token-scoped link with an explicit revoke, and treat Tailscale-first as the default rather than the fallback.
Disclosure: I'm building AQ (aq.dev), which lives in this same problem space (agent sessions that keep running after you close the laptop, joinable from a browser), so I've spent a lot of time on exactly these two questions. We compared the options, including the plain VM plus tmux route, here: https://aq.dev/guides/keep-claude-code-running-after-closing...