I think a significant distinction between your approach and Claude’s approach is that your approach requires allowing your machine to accept inbound connections but Claude’s approach does not. Claude probably went with the latter to avoid a whole class of security issues and mitigate risk of users having their machines compromised. I’m not familiar with what the new vectors of attack are with Claude’s approach though.
replyYeah the remote control featureset is pretty limited right now. I did a comparison here https://yepanywhere.com/claude-code-remote-control/ (with my own project). I'm sure they'll iterate on it. Overall it's such an obvious feature for them to add I'm surprised it took them so long to ship. There are probably at least 50 such projects that people have made (https://github.com/kzahel/yepanywhere/blob/main/docs/competi...)
replyThe one feature drawback of tailscale/tmux/termius is no file upload. And ergonomics, ability to view files/diffs easily, though that's subjective.
Perhaps it took a while to figure out how to do it over HTTP, especially the security stuff.
replyWith e.g. tmux you'll piggyback on decades of SSH development.
> SSH development.
replyOr Mosh, just like OP said. Mosh handles interruptions much better than SSH does
As I understand it, Mosh piggybacks on SSH. Have they recently dropped the SSH negotiation?
replyWhich is so much better because you can do other terminal stuff and you can avoid vendor lock in.
replyThat's not what vendor lock in means. If you sign up for a cloud hoster and then build your whole product on propriety services that you can't get anywhere else instead of using an off the shelf database or open source software, that's vendor lock in.
replyIf you'd have to switch to a different tool to do your coding that's not vendor lock in.
In this case you are locking your workflow to the vendor's solution.
reply