sebderhy

I used exactly this setup before (mosh + tmux + Tailscale + VPS), so maybe I can help. Both tools are terminal UIs, so they fit naturally in what you have: you run them inside tmux on the VPS, and mosh handles the bad connection like it does for everything else. But honestly they don't change much when the connection is bad, because the UI still goes through the connection. This is one of the reasons I built ShellTeam (github.com/sebderhy/shellteam): the sessions stay on the VPS and the UI is a web app, so when I lose internet on a train I just reload the page and everything is still there. I'm obviously biased, but for intermittent connections I think a web UI works better than a TUI over mosh.

Hey HN. Like many others, I'm running my coding agents almost exclusively on my VPS. But I got tired of the terminal as the interface: I tried Termius on my phone but it was quite painful the moment I tried to paste screenshots or record voice notes. The best thing I found was Claude's remote-control feature, but it locks me to one coding agent / LLM provider, and therefore I'm stuck as soon as I hit my usage limit.

This is why I built ShellTeam, an open-source cockpit to steer the coding agents on your VPS. It puts your existing coding agents (Claude Code, Codex, Antigravity, OpenCode) behind one mobile-friendly web app: start a task with a voice note, paste screenshots, and every file an agent writes gets a URL only you can open, every port it serves gets a subdomain.

15-second demo: https://github.com/sebderhy/shellteam/raw/main/docs/assets/d...

The clip shows the part I like most: a chart is pasted, Opus reads it, then the thread is switched to GPT-5.6 by the user with a dropdown and it answers using the previous turns with Opus. ShellTeam translates the session into each CLI's native session-file format, so the target agent resumes it as its own. Actually, this GIF, as well as most of ShellTeam, was built through ShellTeam.

I know that many of you probably already have a setup for your coding agents, so I tried to make ShellTeam strictly additive. It does not touch ~/.claude.json or ~/.codex/config.toml (a CI test asserts your own claude/codex stay byte-identical), and with the "minimal" (default) install, spawns your CLIs with zero additions. An optional layer adds skills, a headless browser, and a nightly knowledge pass, but they are passed as launch flags, not written to your dotfiles.

Other small but important facts about ShellTeam: * It is private by default: everything binds 127.0.0.1, and you reach it over Tailscale, or you can wire it to your own domain. * There's no telemetry. The only way data can flow to me is if you submit a bug to the product. * The agents are not sandboxed, on purpose: the VPS on which you install it is the boundary. So install it only on a machine where you'd let your coding agents run anyway. ./install.sh --plan prints every change it would make to that machine (units, sudoers, ports, files) and exits without touching anything. * License is AGPL-3.0. I also offer a VPS with ShellTeam preinstalled (--full version) at $19/month for people who want an easy path to start using coding agents. Anything you build with it stays yours.

I've been using it for months now and can't imagine going back to SSH + terminal, but this is the first time I'm putting it in front of others: I'd love a few people to try it on their own box and tell me how it goes (or ask your agent to). It is hopefully easy and safe to try: the install is additive, uninstall.sh removes everything, and if your setup lives on your laptop, a one-command mirror (in beta) imports it onto your box.

Hope to hear *your coding agent's* feedback!

Yeah, I have to say that finding the right balance between what to write and not to write in the AGENTS.md is quite hard.

Regarding the protocols being unstable, that's quite a fair point. Maybe it is possible to automate this? That is, detecting changes in the official docs automatically, and adapt the docs and tests automatically based on it via a Coding Agent.

Hi, author of the repo speaking here!

When I tried building MCP Apps [1], the official repos (https://github.com/openai/openai-apps-sdk-examples, https://github.com/modelcontextprotocol/ext-apps/tree/main/e...) were great starting points, but they're designed for human developers. When I used them with Claude Code, I ended up in the usual loop: agent writes code → I manually test the app on ChatGPT → describe errors back → repeat. Plus, we didn't know what the best practices are, and struggled to enforce them.

So I built an MCP App template designed for coding agents to work as autonomously as possible on an MCP app.

The key idea: orthogonal testing. 450+ tests parameterized across 12 widget modules that verify infrastructure (protocol compliance, best practices grade, browser rendering), not business logic. Modify widgets, change data, add features — the tests should still pass. Agents iterate freely and get feedback without a human in the loop.

Other features: - Hierarchical documentation that includes the MCP-App & OpenAI Apps SDK official llms.txt files - Local chat simulator app that works even without API keys via Puter.js - Visual testing of every widget: pnpm run ui-test --tool show_carousel → screenshot at /tmp/ui-test/screenshot.png - 12 working examples (QR codes to 3D solar system) gathered from the official repos mentioned above.

The repo includes an unedited ~15 min video of Claude Code building an app autonomously which worked directly within ChatGPT.

I'd love to hear how it goes if you try it. Or even better: ask for a feedback to your agent, and post it here!

[1] MCP Apps (https://modelcontextprotocol.io/docs/extensions/apps) let you build interactive widgets that run inside Claude, ChatGPT, VS Code, and other AI hosts. In contrast to smartphone apps, the same code can deploy to all platforms.