A native graphical shell for SSH

[1] https://en.wikipedia.org/wiki/DOS_Shell

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.

> 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.

> 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

Both usages (graphical and CLI) of the term are correct. Saying "shell" doesn't by itself imply one or the other, even if the technology that is more commonly discussed when we say "shell" is those CLI things in UNIX-like OSs.

A bit like how cars are typically small vehicles with internal combustion engines, but that doesn't mean EVs are not a classification of cars too.

Just FYI.

https://gitlab.gnome.org/GNOME/gnome-shell

(just as one example)

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?

Download the binary, make a Caddyfile

  myservice.example.com {
   basic_auth {
    admin some_password_hash_here
   }
   reverse_proxy :3000
  }

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

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.

ssh -D 4711 -q -C -N user@host

sets localhost:4711 up as a socks5 proxy you can tell your browser to use

...

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)

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, ...

The terminal has no Platonic quality of being keyboard only. It is an accident of history and the limitations it has had. Remove the limitations and remove the accident of history and you will just end up drawn into the strange attractor of GUIs, warts and all.

There could be a brief honeymoon where the tech stack looks like some of you are imagining in your heads, but it would only last as long as it wasn't used by very many people. Google "gemini protocol" for a similar situation. That protocol has basically a cap on how popular it could possibly get before it just turned into HTTP B as the rest of the world forcibly upgraded it regardless of what the core project thinks. They exist in the shadow of HTTP, as the terminal exists in the shadow of GUIs. This is not a bad thing. It is what lets them be what they are. The shadows of GUIs or HTTP is large and there is plenty of space to be. Trying to give the terminal more GUI capabilities is like trying to give Gemini more web capabilities; you'll just end up in the same place, only with less refinement.

(The one on the website is the standard browser video player, not custom.)

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.

Cool idea anyway, no shade here.

It does. MobaXterm have a bunch of it already, file manager on the side and ability to pass X11

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

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/)

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).

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.)

[0] https://terminal.click

[1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

If so how would that work on non Apple devices? Also how much will that sandbox protect you?

https://outerframe.org/ and https://outerloop.sh/native-apps/

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.

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.

"Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer

Some ideas like using viewing a linux dir over _ssh_ using native UI components.. seem cool.

I do agree, some of these do seem like they have already been solved in other ways (like an sshfs mount).

Funny enough, that right there is the actual fundamental problem here.

I am reminded of a post or blog long ago that talked about programmable thermostats and how awful they are for most people to use despite how powerfully in the weeds one can get with them. Basically summarizing the issue as something like “People do not want to learn your arcane system, they just want the benefit it’s advertising”. A good UI knows how to minimize that gap.

The poster child of this is the Microsoft Office ribbon.

I want to set the temp. Maybe set a schedule and a timer. Once I have to start navigating multiple, deep menues with a thermostat I stop giving a shit.

I miss old VCRs that had 8 buttons and only those 8 functions

p9 was done when "current state of unix" was already fixed in form of aix, sysv and bsds, it suffered the same fate as say beos.

but unix got widely adopted and you go with what sells not blue-sky woulda-coulda

Almost all dev facing machines have ssh server installed and accessible.

Why ssh terminal has to look like character-only trash from 1960s? Why a TUI is the best thing we pipe through ssh? Why I cannot watch a 4k movie in the terminal or browse the web using pinch to zoom ?

`ssh -XC` (look up SSH X forwarding). You can also easily tunnel remote desktop over ssh.

> Why I cannot watch a 4k movie in the terminal or browse the web using pinch to zoom ?

Kitty, sixel, and iterm2

I do agree that new Linux users who have different needs from their computers might cause some incentive to change some of these 40 year old UX decisions. We don't really have a modern, capable remote desktop solution at least on par with RDP.

You take that back!

>Why a TUI is the best thing we pipe through ssh? Why I cannot watch a 4k movie in the terminal or browse the web using pinch to zoom?

The old magick speak of X forwarding. The newer wizards now use waypipe.

We should re-implement it with Comic Sans and happy shiny buttons to click everywhere? Click here for "ls -alh" ?

you want your GUI then set up VNC