You can now browse this site in your terminal:

ssh agnelnieves.sh

No install. One Rust binary that runs as either a local CLI or an in-binary SSH server. No system sshd, no user accounts, no auth. The TUI is built with ratatui; the SSH layer is russh; render code is shared between local and remote modes. It's hosted on Fly.io behind a dedicated IPv4, and the whole thing costs about $2/mo. The code lives as a cli/ package inside the same Next.js project that powers this site, so the website and the terminal share a single deploy story. If you want the full build (architecture, code, Fly.io setup), I wrote it up as a step-by-step guide.

The setup

ssh agnelnieves.sh. That's it. No -l user@, no keys to add, no first-time signup. The server accepts whatever username your local SSH client offers and drops you straight into a terminal UI.

Press h/a/b/c to jump between Home, About, Blog, and Connect. j/k (or arrows) to navigate lists. Enter to open. q to quit, which closes the SSH session.

Why I built it

Honestly? I saw terminal.shop and thought it was awesome. They sell coffee at ssh terminal.shop (that's the whole storefront, no website) and the first time I tried it I wanted to know if I could build something like it.

I do side projects like this when I need to step away from whatever I'm shipping day-to-day. They're not pitches. They don't need a thesis. They're more like the way some people fix a bike on a Saturday: sit down, follow whatever's pulling on your curiosity, and at the end you have a thing that didn't exist before. That's the whole reason.

So this was that. A few evenings poking at ratatui and russh to see what it would take to make ssh agnelnieves.sh actually work. Turns out: less than I expected. The hardest parts were the ones I didn't see coming, which is what makes any of this fun.

The architecture

One binary. Two modes. One render path.

            ┌─────────────────────────────┐
            │     agnel  (single .exe)    │
            └──────────────┬──────────────┘
                           │
            ┌──────────────┴──────────────┐
            │                             │
       agnel (no flag)             agnel --serve
       Local TUI                   SSH server (Fly.io)
       crossterm stdin             russh + custom backend
            │                             │
            └──────────┬──────────────────┘
                       │
                src/render.rs   ← shared
                       │
                Per-session App state
                       │
                Live fetches from agnelnieves.com APIs

The pieces:

• TUI: ratatui draws everything: header, ticker, ASCII banner, projects list, blog reader. The render function lives in src/render.rs and is identical whether the binary is running on your laptop or whether you're seeing it over SSH.
• State machine: App in src/app.rs owns screen, scroll position, list selection, ticker animation, and async-fetch results funneled through an mpsc::Receiver.
• Data: zero content is bundled. The CLI fetches live from /feed.json, /api/blog/[slug]/raw, /api/projects, and /api/site.json on this site, cached for an hour at ~/.agnel/cache/. So a new blog post here shows up in your terminal immediately without redeploying anything.
• SSH server: russh 0.60 in src/serve.rs. One tokio task per session.

The decision that made it easy: don't fork a PTY

Most "expose a TUI over SSH" guides suggest spawning a pseudo-terminal and exec-ing the TUI binary inside it. That's how mosh, tmux, and Go's wish library (the one terminal.shop uses) handle things. It works, but it's heavier:

• Adds a libc dependency (forkpty)
• Forks a process per connection (more memory, slower spawn)
• Hard to share state between the SSH layer and the app

Russh's ratatui_app example showed a cleaner path: implement a custom std::io::Write backend that funnels bytes through russh's Handle::data(channel, bytes) API. Ratatui doesn't know it's writing to an SSH channel instead of stdout. No fork, no PTY, just bytes:

struct TerminalSink {
    sender: UnboundedSender<Vec<u8>>,
    sink: Vec<u8>,
}

impl std::io::Write for TerminalSink {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        self.sink.extend_from_slice(buf);
        Ok(buf.len())
    }
    fn flush(&mut self) -> std::io::Result<()> {
        if !self.sink.is_empty() {
            let _ = self.sender.send(std::mem::take(&mut self.sink));
        }
        Ok(())
    }
}

A background tokio task drains the channel and pushes bytes back to the client through russh. Each session gets its own App and its own Terminal<CrosstermBackend<TerminalSink>>. The lock graph stays tiny: an Arc<Mutex<SessionState>> per session, plus a HashMap of all sessions for cleanup.

Inputs go the other direction. Russh hands raw bytes to my data() callback, and a small parser turns them into the same crossterm::event::KeyEvent values the local TUI uses. That meant zero changes to App::handle_key:

fn parse_keys(buf: &[u8]) -> Vec<KeyEvent> {
    // 0x03 → Ctrl+C, 0x1b[A → Up, 0x1b alone → Esc,
    // printable ASCII → Char(b), etc.
}

Window resize hooks into the same place. window_change_request calls terminal.resize(rect), and ratatui redraws on the next 50 ms tick.

The result: a single binary you can drop on a VPS, in a container, or even into a Lambda-style worker, and it just serves the TUI.

What I learned about hosting

A few things I didn't expect.

1. Fly trial orgs block dedicated IPv4, and SSH needs IPv4. For HTTP, Fly's edge gives you a shared anycast IPv4 for free. For raw TCP on port 22, you need a dedicated v4 (~$2/mo), and trial orgs can't allocate one. Pure-IPv6 isn't a real option, either: most US residential ISPs still don't have native IPv6 SSH paths. Adding a card was the unlock.

2. The SSH host key has to persist. If the container generates a fresh Ed25519 key on every boot, every returning visitor gets REMOTE HOST IDENTIFICATION HAS CHANGED warnings after the next deploy. The fix is a 1 GB Fly volume mounted at /data, with --host-key /data/ssh_host_key. First boot generates and writes the key; every boot after just reads it.

3. Trial machines auto-stop after 5 minutes. That's how the Fly free tier nudges you toward billing. Once you're paying, set auto_stop_machines = "off" and min_machines_running = 1 if you want a long-running service.

4. fly proxy is fine for HTTP, weird for raw SSH. I burned half an hour on Connection reset by peer through fly proxy 12222:2222 before realizing I should just bash /dev/tcp/127.0.0.1/2222 from inside the machine via flyctl ssh console. The SSH server was healthy the whole time; the proxy path was the problem.

ANSI Shadow beats slant

The first banner I shipped used figlet's slant font. It looks fine in a docs file. At terminal width with full-block rendering, it falls apart into disconnected diagonals.

Swapped to ANSI Shadow, the same boxy block font terminal.shop and charm.sh use. Six rows tall, about 93 columns wide, reads instantly. Probably the kind of thing I'd have gotten right the first time if I'd looked at more references before opening figlet.

Visitor #N

One fun thing I added. Look at the bottom-left of the footer when you connect: it says visitor #N. First SSH session ever was #1, second was #2, and so on. The count lives in a tiny text file on the Fly volume next to the host key, increments once per channel_open_session, and persists across deploys (host-key lesson applied).

Implementation is about thirty lines. An AtomicU64 loaded from the file at startup, a spawn_blocking write after each fetch_add. The file is just a base-10 number with no header, so cat /data/visitor_count is the dashboard.

There's no leaderboard. No real meaning to the number. But watching it tick up after shipping is the moment the whole side project starts feeling worth it.

The stack

What's next

• Pretty errors and loading states. Today they say Loading… which is functional but boring.
• Project deep-links. I render project metadata but not the original write-ups. Pulling MDX through the API would let me ship long-form case studies in-terminal.
• Cross-platform release binaries. The current install path is cargo install --path cli/. Homebrew tap + release artifacts for macOS and Linux is a Saturday morning.

Try it

ssh agnelnieves.sh

If you want to build your own version, the guide has the full setup (Rust + ratatui + russh + Fly.io), with a copy-paste prompt at the top so you can hand it to your AI agent of choice. If you ship one, let me know.

Built by Agnel Nieves, a design engineer with 15+ years across product, design systems, and crypto. More writing on the blog.

My co-founder peroni and I did the only sensible thing. We shipped it.

What Happened with the Claude Code Leak

If you missed it, here's the short version. Chaofan Shou (@Fried_rice) noticed that version 2.1.88 of the @anthropic-ai/claude-code package on npm included an unminified source map — cli.js.map — containing the full, readable TypeScript source. By 4:23 AM ET, it was public. By noon, the internet had catalogued every hidden feature, internal codename, and unreleased capability Anthropic had been quietly building.

Among the bigger discoveries:

• KAIROS — an always-on daemon mode that lets Claude Code operate as a persistent background agent, watching, logging, and acting without waiting for user input
• Undercover mode — auto-activated for Anthropic employees on public repos, stripping AI attribution from commits
• 44 feature flags covering unreleased functionality
• And tucked away, a complete companion pet system called Buddy

The Buddy System: A Pixel Pet for Every User

The Buddy system was fully implemented. Every Claude Code user was supposed to get a unique pixel creature generated deterministically from their user ID. Same hash, same buddy, every time. The code included 18 species across rarity tiers, stat generation, personality descriptions — the whole gacha experience, just waiting to be turned on.

It was the kind of detail that makes you smile. In a tool built for productivity and code generation, someone at Anthropic took the time to build a pet system. A little pixel friend that lives in your terminal. That's the kind of craft and whimsy that makes developer tools memorable.

The moment I saw it, I knew what we had to do.

From Discovery to Deploy in a Day

Peroni and I have a rhythm. We spot something interesting, we build. No planning committee, no Jira tickets, no "let's circle back Monday." As a design engineer with 15+ years of shipping products, I've learned that the best side projects are the ones you can't not build. This was one of those.

We built Claude Buddy — a web app that lets anyone generate their own pixel companion. Type your name or your Claude Code user ID, and watch it draw your buddy pixel by pixel, complete with retro CRT animations and pop sounds.

Here's what we shipped:

• 12 unique pixel art species across 5 rarity tiers — from common Blobbits to the legendary Nebulynx (3% chance)
• Deterministic generation — same name always produces the same buddy, making them feel like yours
• Shiny variants with a 5% drop rate, because of course
• Buddy stats — Vibe, Chaos, Focus, and Luck, each randomly rolled but consistent to your hash
• One-command terminal install — curl a script and your buddy appears in your Claude Code statusline
• Social sharing — download as PNG, share via URL, generate QR codes, post to X/LinkedIn with pre-populated text

The whole thing runs on Next.js 15, renders sprites on HTML5 Canvas, and uses a Mulberry32 PRNG seeded by a DJB2 hash of your input. No backend, no database, no authentication. Pure deterministic fun.

Why Build This?

Partly because it's fun. Partly because of how I approach creative work — I try to ship a hackathon-style project every quarter to stay sharp and experiment with new patterns. But mostly because I think the Buddy system represents something important about how we relate to our tools.

Developer tools don't have to be purely utilitarian. The best ones have personality. They reward curiosity. They make you want to open the terminal. A pixel pet that lives next to your cursor won't make you a better programmer, but it might make the work feel a little less solitary.

Anthropic clearly felt the same way — they built the whole thing, ready to ship. We just opened the door a little early.

How the Generation Algorithm Works

For the technically curious, the generation is straightforward:

1. Take the input string (name or user ID), lowercase and trim it
2. Salt it with a fixed string to avoid collisions
3. Run a DJB2 hash to convert it to a numeric seed
4. Feed that seed into a Mulberry32 PRNG
5. Roll for species (weighted by rarity tier probabilities)
6. Roll for shiny status (5% chance)
7. Generate four stats between 1 and 99
8. Select a soul description from the species pool

Same input, same seed, same rolls, same buddy. Every time. No server involved.

It's Open Source

The entire project is open source on GitHub. Built by the Basement team. Fork it, remix it, hatch your own buddy.

If you want to see what came out of this, check the thread on X where we announced it. And if you're building with Claude Code, maybe your buddy is already waiting — just type your name and find out.

Have thoughts on this or want to collaborate on something weird? Let's connect.