It does need an agent that starts with every X or Wayland session and waits for requests from remote SSH sessions to start an app.
As someone managing various servers, both at home and at work, I see how this can be really useful. I see it not in the production space yet but rather in the experimenting, using a Linux machine as a second compute device!
So regarding your last point, I'm convinced. I think it is useful! The one fact that is bugging me is that now it requires a client specific app, with GUI, on my PC and I wonder if using ssh port forwarding could reduce the surface. I mean I wonder if either having a rich client that executes commands via ssh or a rich server (including Web Server) with ssh port wouldn't suffice, so that I can avoid installing stuff on the server AND on my computer.
> Apps like Jupyter and Tensorboard are not typically visible to standard web browsers if they’re running on remote servers, because it would be terribly unsafe to let the whole internet touch this app. Instead, they run on a local port on the server, which your computer can’t access directly.
> Classically, to get access to these, you had to open a new terminal and run:
> ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &
> ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &
is this true? isn't the normal thing just to do this ssh forwarding for prototyping, then for deployment, you set up a website like myjupyternotebook.com, and then set up auth so that others can't access it. HTTP basic auth is not too much work.
if you want SSH, not HTTP, to be what's publicly exposed, there's other options too, like putting it behind a VPN or tunnel.
all this to say, outer loop is super cool, but I don't get it. I must be missing something about why you built it, so could you help me understand?
If so how would that work on non Apple devices? Also how much will that sandbox protect you?
I take it you don't know about "X11Forwarding yes" or "html5 web app"
For browsers, capabilities like connecting to Unix sockets have been dismissed as extremely niche
The tool from OP and WAC are pretty similar in terms of functionality and usecase. Why would you want this? Well, imagine your team needing to be able to do server functions but you have less technical team members to do it for you, which is very often the case in big places, most people are familiar with the web browser and having a website to do these sorts of actions makes it easier to have things done in one place without a lot of tools like Remote Desktop, SSH, WinRM, etc. configured.
It does. MobaXterm have a bunch of it already, file manager on the side and ability to pass X11
This adds unnecessary overhead for communication. using web and web-like approaches on desktop system is a terrible idea.
My terminal's "clickity clackity" features [0] are local to the machine so I lose graphical-ness as soon as we remote in somewhere.
That's starting to change a bit with offline replay [1] where the native GUI and TUI work in tandem to unlock some rewind. But there's quite a road ahead and I love seeing others experiment properly. (Terminals are massively underserved.)
[1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...
Cool idea anyway, no shade here.
Dependencies are less of a concern for the frontend binaries. For backends, I use a dependency-light approach, static-linking anything that's needed. Of course, people are welcome to do backends however they want, and just tell Outer Shell about the systemd/launchd units via the API. I used this no-dependency approach to keep everything lightweight and to keep install steps trivial, but admittedly it pushes me in certain directions (for example, using custom binary formats rather than sqlite).
ssh -D 4711 -q -C -N user@host
sets localhost:4711 up as a socks5 proxy you can tell your browser to use for
...
A wireguard VPN is better of course; among other things because ssh is multiplexing over a single TCP connection and will encounter head of line blocking (where one dropped packet blocks all forwarded traffic until resent)
I'm closer to the cluster that uses them for deep learning experiments, GPU kernel optimization, robot development (a robot is just a server that moves!)... use cases where you are explicitly using a remote computer.
For this cluster of people, I think this tool feels more intuitive than the flow you suggest. But maybe I'm projecting!
And, to me, this just feels like one of the fundamental things that could exist; it's like a graphical operating system, but remote-first.
(The one on the website is the standard browser video player, not custom.)
SSH protocol also isn’t just for CLI work. It supports file transport (eg SFTP), TCP/IP forwarding and even SOCKS HTTP proxying.
You also used to be able to run GUI applications over SSH via X11.
https://outerframe.org/ and https://outerloop.sh/native-apps/
On various Mozilla forums that I saw, the discussion was basically: 1. We can't just allow the browser to connect to any socket, since many either explicitly don't want browsers connecting to them, or are oblivious to browsers. 2. ...so we need to also add some sort of allow list 3. ...this is getting too complicated for such a niche feature.
So I think the nicheness was the high-order bit here.
(FYI, Outer Loop does add an allow-list: https://outerloop.sh/unix-domain-sockets/)
What I mean is that we can bring some web tech to terminal natively. We don't even need a separated shell. Security and bi-directional communication is built by default because of UNIX socket. But we still need to think how to handle stuff like cookie, local storage, external CSS / JS, ...
Download the binary, make a Caddyfile
myservice.example.com {
basic_auth {
admin some_password_hash_here
}
reverse_proxy :3000
}
It's a fun heretical idea, moving away from a "cross-platform" web to a "multi-platform" web. It's a cross-platform protocol that hands off to platform-specific frontend code. I think it's a natural direction for the web, in a world where LLMs can translate to other platforms.
Just FYI.
> An operating system shell is a computer program that provides relatively broad and direct access to the system on which it runs. The term shell refers to how it is a relatively thin layer around an operating system.
> Most shells are command-line interface (CLI) programs. Some graphical user interfaces (GUI) also include shells.
The last line I think supports the notion that the term "shell" at least implies a CLI, but I can understand both positions.
---
0. https://en.wikipedia.org/wiki/Shell_(computing)
Edit: I'm shite at formatting on HN
> Cairo, like Chicago, had a new shell (Microsoft’s favorite word for the user interface for launching programs and managing files) and a new file system
https://hardcoresoftware.learningbyshipping.com/p/020-innova...
When I worked at Microsoft 2010 - 2014, the word "shell" was still used in this way. I decided to say "graphical shell", to make it clearer.
The original intent was that a shell is a thin wrapper on top of the OS to expose the hosts capabilities. But that hasn’t been an apt description for most of those 40 years.
domain1.com -> service on port 1234
domain2.com -> service on port 5678
domain3.com -> serving a file directory.
And then you still access domain1.com, domain2.com, domain3.com on port 80/443
With the web browser, we have really figured out a good flow for how one device (the “server”) can provide an experience on another device (the “client”).
This raises a fun idea: imagine if servers and edge devices could serve up a browser-based graphical “shell” so they can be used from other devices. The shell would provide a home screen of apps. In this shell, every app is a small HTTP server, serving up a web user interface. The shell would provide an API so that apps can look up each other’s URLs. For example, apps could register themselves as a text editor, so you can double-click text files in one app to open them in the editor app. These graphical apps would be an alternative to terminal-based apps.
These HTTP servers will typically be private, inaccessible to other devices on the network. Instead, you’ll use them over SSH, or locally. Unlike most existing web-based server tools, these HTTP servers won’t typically use localhost ports, but instead will use Unix domain socket files, which are similar to ports but live on the filesystem with explicit user permissions. Each HTTP server can be very simple, with no dependencies, because it doesn’t have to handle encryption, which instead happens at the SSH layer.
The apps can be conventional HTML-based web apps, but they can also be native outerframe apps.
I’ve built Outer Loop into an SSH browser for this type of graphical shell, and now I’m shipping an open-source Outer Shell.
Here I demo Outer Shell and how it works, and I try to give you a sense of how much low-hanging fruit there is in this space.
UPDATE: Here’s a YouTube mirror, for people who prefer that.
Instead of writing an enormous blog post, I wrote a bunch of documentation:
Isn’t it weird that this doesn’t already exist? For browsers, capabilities like connecting to Unix sockets have been dismissed as extremely niche, but when you group it together with the right set of other capabilities (including SSH and sudo awareness), entire new branches of the tech tree become apparent. Instead of treating Linux (and other) servers as having conventional local graphical operating systems, we could focus on giving them “outer” graphical shells for remote devices. In an alternate timeline, we’d have been building out this ecosystem for decades, using conventional HTML / JavaScript apps. Many individual server-style web apps like Jupyter and Tensorboard did in fact appear, each with their own one-off security protocols, but nothing really arose to deliver them “correctly”.
And now, the opportunity is even bigger, because we can make the apps truly native. Now that we have AI that can help us write code, it is practical for each app to have a codebase for each target platform. I think this is becoming the natural architecture for the web: HTML for reading and casual apps, and native platform-tailored apps for getting work done. Why settle for less?
(Thanks to Rosanne Liu, Mirko Klukas, Adam Zethraeus, and Felix Andrews for reading/viewing drafts of this post and screencast.)