Most of my machines have a coding agent installed these days: Claude Code, Cursor, OpenCode and friends. They're surprisingly good at systems work: reading logs, restarting a service that fell over, figuring out why a disk filled up. The catch is that they live in a terminal, and when something breaks you're rarely sitting at one. You're on your phone.

That's where Glassys comes from. I started it on 8 September and it's my newest project, open source like the rest.

What it is (and what it isn't)

Glassys is a self-hosted chat face for the agent that's already on the machine. A small Node gateway talks to each vendor's local SDK (Claude Agent SDK, Cursor, OpenCode, Codex, Gemini CLI, or anything that speaks ACP), translates each one's stream into a single UI protocol, and serves a PWA you open from your phone or another computer.

The closest analogy: Open WebUI is to Ollama what Glassys is to these agents. The UI, not the runtime.

It's also worth saying what it isn't, because I had to keep reminding myself:

  • It isn't the agent. It doesn't infer anything and has no personality. If the agent is wrong, Glassys shows you it being wrong.
  • It isn't an IDE. The job is operating the machine: services, files, git, the system itself. For writing application code, your editor is still the right place.
  • It isn't a SaaS. Each person runs their own instance on their own host.

The v1 is deliberately small: one profile, one agent, one live thread, and runs that queue up one after another. The gateway installs as a user service with a single command.

Three weeks, three stages

The first version (8 September). Threads that survive reconnects, the adapters, the installer and a PWA you could already use from a phone. It worked, but the interface had grown by accumulation: one CSS file of almost 850 lines, a dozen font sizes (some one pixel apart) and seventeen spacing values without a scale.

A real design system (9 September). I rebuilt it on explicit scales: 4px spacing, six type steps, five radii, three elevations. A persistent rail on desktop, a tab bar on the phone, a composer that no longer jumps in height while you type, and my own confirmation dialog instead of the browser's, which showed the gateway's URL. Then an audit done by measuring rather than by eye: two grey tokens failed AA contrast in both themes, the focus ring painted a near-black halo on light surfaces, and a status pill sat 13 or 51 pixels from the edge depending on the card. To keep it from coming back, a check now runs with the linter and fails the build if a component uses a raw size, if a colour pair drops below AA, or if a class isn't used anywhere.

The machine next to the chat (23 to 26 September). This is the part I like most. An Activity panel shows what the current thread has done to the host. And there are four read-only views next to the conversation: overview (uptime, load, memory, every disk with its usage), services, logs and files. The agent is the one making changes; the views are there so you can check what it did without asking it. The runs changed too: a run that touches a dozen files is no longer a wall of tool cards but a readable sequence of grouped steps.

Along the way I tightened the gateway: it takes the allowed CORS origin from its own allowlist instead of trusting the request, only trusts its own origin, doesn't put internal errors in its responses, and gives every atomic write its own temporary file. None of that is visible, and that's how it should be.

Where it stands

It's usable today. It still has rough edges: Gemini's SDK isn't on npm yet, Codex and OpenCode need their binaries on the PATH, and a single live thread is a limit I chose, not a permanent one.

If you have agents on your own machines and have ever wanted to talk to them from the couch, the repository has installation instructions and screenshots of the current interface. Issues are welcome.