{
    "version": "https://jsonfeed.org/version/1",
    "title": "Astrohacker Blog",
    "home_page_url": "https://astrohacker.com/blog",
    "feed_url": "https://astrohacker.com/blog/feed.json",
    "description": "Dispatches from the Astrohacker portfolio.",
    "author": {
        "name": "Ryan X. Charles",
        "url": "https://astrohacker.com"
    },
    "items": [
        {
            "id": "https://astrohacker.com/blog/2026-08-10-keypears-coming-home-to-astrohacker",
            "content_html": "\nPassword managers store secrets. Chat apps send messages. Email is federated\nbut not end-to-end encrypted in any way that helps you hand someone a database\nURL without also handing it to a dozen intermediaries.\n\nNone of them do all three well: **hold secrets under your key**, **send private\nmessages across operators**, and **share a secret the way you share a DM**—then\nlet the recipient put it in *their* vault.\n\n**KeyPears does.** It is a hybrid post-quantum federated end-to-end encrypted\nmessaging system and password manager. The network shape is like email. The\nsecurity baseline is built for 2026. And it is coming home under\n[Astrohacker](https://astrohacker.com).\n\n## What KeyPears is\n\nShort version:\n\n- **Messaging** that is end-to-end encrypted by default, with hybrid classical\n  and post-quantum crypto on the normal path—not a “secure mode,” not an\n  enterprise checkbox.\n- **A vault** for passwords and other secrets. The node stores ciphertext. Your\n  client unlocks and encrypts. The operator of a node is not supposed to read\n  your logins or notes.\n- **Addresses like email:** `name@domain`. You talk to people on other domains\n  the way email talks to other mail servers.\n- **Anyone can run a node.** The network is multi-operator by design, not a\n  single company silo wearing a federation sticker.\n- **Discovery and delivery** follow an email-shaped architecture: domains,\n  well-known configuration, pull-style delivery between nodes—not one global\n  chat host that owns every conversation.\n\nThis is what “email for 2026” means in practice: the social model people already\nunderstand (addresses, domains, someone else’s server), without SMTP-era\nplaintext and without pretending a SaaS inbox is the same thing as a protocol.\n\nWe already said the hard crypto part out loud. KeyPears went hybrid post-quantum\non the default path—every message, every signature, every account. That write-up\nis still the right reference for the construction:\n[KeyPears Goes Hybrid Post-Quantum](/blog/2026-04-27-keypears-hybrid-post-quantum).\n\n## Already launched — now moving home\n\nKeyPears is not a fresh pitch deck. It launched earlier as its own product\nsurface in the Astrohacker portfolio—secret exchange, messaging, identity under\none roof. See the portfolio intro and the fold-in note if you want the company\ntimeline:\n\n- [Introducing Astrohacker](/blog/2026-04-13-introducing-astrohacker)\n- [Folding the Portfolio into Astrohacker](/blog/2026-07-11-unifying-under-astrohacker)\n\nWhat is new is not the idea. **What is new is where the work lives.**\n\nWe are bringing KeyPears into the Astrohacker home—code, product path, and\ncompany front door at [astrohacker.com](https://astrohacker.com). Legacy labels\nand older hosts can lag. Cutover is project by project. The direction is set:\nKeyPears belongs under Astrohacker, not as a permanent peer brand on a product\nmall homepage.\n\nThis post is a status report, not a product launch URL. No install checklist.\nNo “sign up here” subdomain. When something is ready to use in public, we will\nsay so plainly. Until then: capability and architecture first.\n\n## The password manager half\n\nYou get a vault. Names and types for list and search. Sensitive fields—\nusernames, passwords, free-form notes—live inside client-encrypted blobs. The\nnode can help you find “the GitHub login” without knowing the password.\n\nThat is the boring half, and boring is good. A password manager that treats\ncrypto as plumbing should feel ordinary: unlock, create, edit, lock.\n\n## The messaging half\n\nYou get private channels between addresses. Messages are end-to-end encrypted\nwith the hybrid construction (classical and post-quantum together). Nodes\nexchange ciphertext. Opening a conversation can require proof of work at the\n*recipient’s* difficulty so spam is not free.\n\nFederation is real work, not a slide. Same-domain delivery and cross-domain\ndelivery are both part of the product story: Alice on one operator’s node can\nreach Bob on another, the way email works when two people do not share a host.\n\nThe server still sees addresses, routing metadata, and ciphertext. It does not\nget a free pass into the body of the message.\n\n## The part that matters most for developers\n\nPasswords are table stakes. The interesting product is **secret exchange**.\n\nTeams constantly need to pass:\n\n- environment variables\n- database URLs\n- API keys\n- service tokens\n- other config that should never land in a public channel\n\nToday that material travels through chat apps, email, paste sites, and “quick”\nscreenshares. The history is searchable forever by the wrong people. The\nclipboard is a gossip protocol.\n\nKeyPears treats a vault item as something you can **send as a private message**.\nThe recipient sees a secret card, not a dump of fields in chrome. They can\n**save it into their own vault**, re-encrypted under *their* key, with enough\nprovenance to know it came from a message—without the node reading the secret\nitself.\n\nThat loop—**hold → share → receive → store again under a new key**—is the\nproduct. It is why messaging and the vault are one system, not two apps glued\ntogether with a CSV export.\n\nNo federated system of this shape exists as a coherent product: hybrid\npost-quantum e2e messaging, client-encrypted vault, email-like multi-operator\nnetwork, and first-class **share a secret like a message**. KeyPears is first\nbecause the stack is one protocol story, not a password manager bolted onto a\nchat SaaS after the fact.\n\n## Status: what is real now\n\nHonest list.\n\n**Built and proven in the Astrohacker KeyPears path**\n\n- Account identity with address-shaped names and proof-of-work gates where spam\n  would otherwise be free.\n- Client-side vault unlock and encryption; ciphertext-only sensitive fields on\n  the node.\n- Hybrid post-quantum message encryption and signatures on the messaging path.\n- Same-domain send/receive and federated delivery between nodes.\n- Share a vault secret as an encrypted message; recipient optional save-to-vault.\n\n**In progress**\n\n- Folding KeyPears fully into the Astrohacker product home.\n- Production packaging, discovery, and the open path for other people to run\n  nodes with their own domains.\n- Polish that turns lab-proven paths into something you install without a map.\n\n**Not this post**\n\n- A claim that a new public host is live today.\n- A rebrand name announcement (old posts still say “Astrohacker Keys (TBD)” for\n  a reason).\n- SMTP replacement, mailing lists, or “we fixed compromised devices.”\n\nIf a device is owned or a password is weak, cryptography will not save you. If\nyou need MIME and mailing lists, use email. KeyPears is for secrets and private\nmessages under modern crypto—not for recreating 1995’s mail stack.\n\n## Why under Astrohacker\n\nOne of the through-lines of this company is that **cryptography is plumbing,\nnot a product category**. Money systems and secret systems both need boring,\ndefensible crypto so the interesting product can be something else: cash that\nmoves, secrets you can actually share safely, agents and humans with identity\nunder human control.\n\nKeyPears is the identity, messaging, and secret-exchange layer of that picture.\nIt already showed up as the protocol direction for how services talk when we\nwrote about EarthBucks network plans. Bringing it home to Astrohacker is the\nsame unification story as the rest of the portfolio: one company brand, one\nfront door, protocol-shaped infrastructure that other operators can run.\n\n## What to do\n\nFollow the company blog and [astrohacker.com](https://astrohacker.com). That is\nthe home for status as KeyPears moves in.\n\nIf you care about the crypto baseline, re-read the hybrid post-quantum post.\nIf you care about the company fold-in, re-read the portfolio unification post.\nIf you care about the product: password manager and private messaging, with\n**developer secret share** as the wedge that neither email nor a siloed vault\nsolves alone.\n\nWe are not inventing a new category label for a pitch. We are finishing a system\nthat already had a launch and a protocol spine—and putting it where the rest of\nAstrohacker lives.\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-08-10-keypears-coming-home-to-astrohacker",
            "title": "KeyPears Is Coming Home to Astrohacker",
            "summary": "KeyPears is hybrid post-quantum federated messaging and a password manager—email-shaped addresses, self-hosted nodes, and private secret exchange for developers. It is moving into Astrohacker.",
            "date_modified": "2026-08-10T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-08-02-nexus-host-and-ahnexus-chat",
            "content_html": "\nYou start a local server. You open it with **`ahweb 3456`**. The page is next\nto the shell that launched it. Then you want the other half of a workday:\n**talk to people**—channels, private messages, a console that is not IRC\ncosplay in a separate app.\n\nThat used to mean leaving TermSurf. Now it can mean **`ahnexus`**: a full-pane\nNexus client in the same window, optionally pointed at **our** BBS.\n\nOn [July 29 we shipped bare-port localhost open](/blog/2026-07-29-port-shortcut-and-what-termsurf-is)\nas **v0.1.90**. This post is the **user-facing arc after that**—not another\nbrowser-feel field note. The biggest thing is **Nexus**.\n\n## The short version\n\n- **Hosted BBS** — **[nexus.astrohacker.com](https://nexus.astrohacker.com)** runs\n  our production **Nexus** server (Fargate, durable data, TLS). Operator-grade\n  first; not a claim of a giant public community overnight.\n- **`ahnexus`** — PATH command in the Astrohacker package: multi-channel chat,\n  Console (`>_`), topics, `/me`, channel list, PMs, broadcasts, Login avatar\n  (CLI + form), Settings password change, files browse/transfer.\n- **Files in the browser pane** — the path that started with “system file open\n  works” is much closer to finished: drag upload, downloads, progress—so panes\n  behave like a real desktop browser for upload/save, and Nexus files can move\n  the same way.\n- **Honest residual** — we closed **chat parity as good enough**, not “every\n  Nexus frame.” Secrets, some slash polish, and deeper protocol areas continue\n  under a planning epic. Full official desktop client parity is a horizon.\n\nIf you only remember one sentence: **TermSurf already put the web next to the\nshell; now it can put a real multi-channel BBS client there too—and we run a\nhost you can log into.**\n\n## What is Nexus?\n\n**Nexus** is a modern multi-channel BBS: chat, user messages, broadcasts, files,\npermissions, TLS—the stack documented for clients that speak its protocol.\nUpstream lives at **[github.com/zquestz/nexus](https://github.com/zquestz/nexus)**\n(server, client, trackers, docs). We are a **client** of that protocol, not a\nfork that reinvented the wire.\n\nThe project’s author writes more widely at\n**[thoughts.greyh.at](https://thoughts.greyh.at/)**—engineering notes, OSS, the\nkind of terminal-adjacent work that sits next to why a BBS-in-a-pane is\ninteresting at all. Credit where it belongs; Astrohacker’s job is the\n**TermSurf product surface** and **our** deployment of the server.\n\nWe use path-pinned **`nexus-common`** for framing and types. We do not invent\nchat formats.\n\n## Why host our own BBS\n\nThird-party servers are fine for exploration. Product work needs a host we\ncontrol: deploy, passwords, operator accounts, smoke against a stable name.\n\nSo we stood up **`nexus.astrohacker.com`**—digest-pinned **`nexusd`**, durable\nstorage, public TLS edge. That work closed as **nexus host deploy**. Chat that\nonly worked against someone else’s lag box was never going to be a product\nstory.\n\n## What `ahnexus` is\n\n**`ahnexus`** is the Astrohacker **Nexus TermSurf app**: Rust local server +\nReact SPA, full pane, same install story as `ahcalc` / `ahhelp`.\n\nYou connect (host, account, optional avatar). You get:\n\n- **Channels** — join, leave, send, members, topics (`/topic`)\n- **Actions** — `/me` as real `ChatAction::Me`, not cosmetic italics on normal\n  text\n- **Discovery** — `/channels` lists the server catalog on **Console** (not only\n  rooms you already joined)\n- **PMs** — `/msg nick text`, tabs at `/chat/pm/…` (no messaging yourself; the\n  protocol forbids it)\n- **Broadcasts** — `/broadcast` when permitted; inbound `ServerBroadcast` as\n  Console lines\n- **Console (`>_`)** — system lines, lists, broadcasts—not a place for plain\n  room chat\n- **Avatar** — `--avatar /path/to.png` or pick/drop on Connect; sent on\n  **Login** each session (BBS sessions do not magically keep last week’s face\n  after a full disconnect)\n- **Files** — browse the user area; download/upload through the product path\n\nIt is a **usable multi-channel client**, not a pixel clone of the official\nNexus GUI, and not every protocol module (voice, news, full admin).\n\n### How you try it\n\nApple silicon, Astrohacker cask installed:\n\n```sh\nahnexus\n```\n\nConnect to **`nexus.astrohacker.com`** (or any Nexus host you use). Prefer the\ndocs and in-app help (`ahhelp`) for flags and smoke paths—including\n`--avatar` for scripted login.\n\nPublic TermSurf source stays on the usual track:\n**[github.com/astrohackerlabs/termsurf](https://github.com/astrohackerlabs/termsurf)**.\nInstall remains Homebrew cask **`astrohacker`** when you want the packaged app.\n\n## Files: finishing the pane browser story\n\nThe [July 28 field note](/blog/2026-07-28-since-help-quit-file-open-and-password-plans)\nwas honest: **system file open** worked; the rest of transfer was still coming.\n\nSince then, the transfer path moved a long way: drag-and-drop upload, multi-file\ncases, downloads to disk, progress feedback. That matters for ordinary websites\n**and** for Nexus file areas. A chat client that can list files but cannot save\nthem is a museum exhibit.\n\nPassword-manager and cloud vault work continue under their own epics. This post\ndoes **not** claim a vault launch.\n\n## What we are not claiming\n\n- **Not** “full Nexus protocol done.” We closed **ahnexus chat parity** as\n  good enough for multi-channel use: topics, list, `/me`, PMs, broadcasts,\n  avatar. **Deferred** on purpose: secret channels, join/leave system lines in\n  the transcript, full slash-table polish, every Console notice type.\n- **Not** English shell / model marketplace / wallet as available SKUs.\n- **Not** “we are a model lab.”\n- **Not** a soft-open of every Astrohacker cloud product.\n\nFurther protocol work (secrets, voice, news, admin, deeper users/files, client\nhygiene) is planned under epic **Nexus protocol client parity**—issues and\nexperiments, not a single big-bang rewrite.\n\n## The line\n\nMonorepo product crates moved through the **late 0.1.9x** range into\n**0.1.103** in this window. Public cask version is whatever your tap last\ninstalled; upgrade when you want host, `ahnexus`, and file pins together.\n\n## Install\n\nApple silicon, Homebrew:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nApp: **`/Applications/Astrohacker TermSurf.app`**. PATH tools include\n`ahterm`, `ahweb`, `ahsh`, `ahcalc`, `ahhelp`, **`ahnexus`**, and the Chromium\nhelper as packaged.\n\n## Close\n\nLocalhost by port number was a small gift to a port-heavy day. **Nexus in a\npane** is a larger one: the same layout that holds your agent and your frontend\ncan hold multi-channel chat against a host we operate—or any Nexus BBS you\nchoose.\n\nUpstream protocol and server: [github.com/zquestz/nexus](https://github.com/zquestz/nexus).  \nAuthor’s writing: [thoughts.greyh.at](https://thoughts.greyh.at/).  \nOur public TermSurf source: [github.com/astrohackerlabs/termsurf](https://github.com/astrohackerlabs/termsurf).\n\nOpen TermSurf. Run **`ahnexus`**. Connect. Stay in the window.\n",
            "url": "https://astrohacker.com/blog/2026-08-02-nexus-host-and-ahnexus-chat",
            "title": "Astrohacker TermSurf 0.1.103: Our Own Nexus BBS and a Real Chat Client in a Pane",
            "summary": "Since the port shortcut: we host Nexus at nexus.astrohacker.com, ship ahnexus for multi-channel chat and files in TermSurf, and keep finishing the browser file path—honest about what is still not full protocol parity.",
            "date_modified": "2026-08-02T20:30:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-29-port-shortcut-and-what-termsurf-is",
            "content_html": "\nYour frontend is on **3456**. Your API is on **8787**. The throwaway fixture\nserver from five minutes ago is on whatever free port the tool printed and you\nalready forgot the host half of the string.\n\nYou do not want to type `localhost` again. You want the **number**.\n\nIn **Astrohacker TermSurf**, **ahweb** now treats a bare port as a local\nserver: `ahweb 3456` opens **`http://localhost:3456`**. Same idea if you are\nalready in the browser pane—put **`3456`** in the URL bar and go.\n\n## The tax you stop paying\n\nLocal development is a parade of short-lived HTTP servers. Frameworks,\ndashboards, OAuth callbacks, docs previews, calculators, mock APIs—almost all\nof them are “something on this machine, this port.”\n\nThe full URL is honest. It is also **noise**. You already know the host is\nlocalhost. The only thing that changes all day is the **port**. Re-typing\n`http://localhost:`—or even `localhost:`—is pure tax between “server is up” and\n“I can see it.”\n\nChrome and Safari do not care how you feel about that tax. They live in another\nspace. TermSurf lives **next to the shell** that started the server. The\nbrowser should meet you at the same level of shorthand you already use when you\nread a log line that says `listening on 5173`.\n\n## What you do now\n\n**From the shell:**\n\n```sh\nahweb 3456\n```\n\n**From the URL bar** (Control mode, edit the location, submit):\n\n```text\n3456\n```\n\nBoth mean: open **HTTP on this Mac, that port**. No host. No scheme typing\nceremony for the common case.\n\nYou still use full URLs when you need them—`https://example.com`,\n`localhost:3456` with the host spelled out, real paths. The port shortcut does\nnot replace the web. It removes friction from the case you hit most while\nbuilding.\n\n## Why this is more useful than it looks\n\nA small shortcut is only small if you use it once. Agentic and terminal-first\ndays are **port days**:\n\n- You spin a UI, open it, kill it, spin another.\n- An agent prints a local URL; you only need the number.\n- You keep two services up and jump between ports without leaving the terminal\n  window.\n- You demo a pane layout: shell in one, local app in another—handoff is a\n  four-digit gesture, not a mini-essay in the address bar.\n\nTermSurf’s job is to keep **computer and web** in one place. If opening the\nlocal web still feels like “go use a different app and type a hostname,” the\nproduct is fighting itself. Bare ports are the product agreeing with how local\nservers actually work.\n\n## The day\n\nStart the frontend. Type the port. Pane loads. Hit the backend health route on\nanother port. Flip back. Stay in **ahterm**. Keep the coding agent where it is.\nDo not Cmd-Tab to a browser profile that still has your bank tab from last\nnight.\n\nThat loop shows up every time something listens. The shortcut only pays off\nbecause the browser already lives next to the shell—which is the product.\n\n## Astrohacker TermSurf\n\n**The Agentic Hacker’s Terminal.** The installable product is **Astrohacker\nTermSurf**.\n\nIt is a **terminal emulator** with a **webview overlay protocol**: real browser\nengines can run **inside terminal panes**, not only as a separate OS browser.\nYou browse the web, hack the web, and show real GUIs next to the shell—same\nwindow, same session, same muscle memory for splits and focus.\n\nDesigned for **agentic engineers** who want maximum power over **their own\ncomputer and the web**—not a toy embedded WebView, and not four consumer SKUs\npretending to be one product.\n\n### Three layers you actually use\n\n- **Terminal** — Ghostty-class host (`ahterm`). Panes, tabs, serious terminal\n  behavior.\n- **Browser** — Chromium-backed panes (`ahweb`). Real engine, real pages, in\n  the layout you already split for code and agents.\n- **Shell** — Nu-powered product shell (`ahsh`), with traditional shell escape\n  hatches as the product documents them.\n\nUnder the hood that maps to engines and tools people already trust (Ghostty,\nChromium, Nushell). You install **one** desktop package—Homebrew cask\n**`astrohacker`**—not a shopping cart of peer apps. The CLIs are components of\nTermSurf, not separate marketed products.\n\n### What ships vs what does not\n\n**Ships today (Apple silicon macOS):** the desktop terminal, browser panes,\nshell, and the helpers that make panes work. Traditional terminal workflows\nwork **without** an Astrohacker account.\n\n**Not available as “use it now” product** (direction only until we say\notherwise): English default AI shell, model marketplace, hosted models as a\npublic SKU, free-credit soft launch, wallet / Economy commerce surfaces. We\nbuild toward an agent-native future; we do not fake the inventory.\n\nThe **cloud** side of the company is **in progress**. You do not need a web\naccount to install TermSurf and work offline. When cloud is ready for ordinary\nuse, we will say so in plain English—not as a scavenger hunt.\n\n## Install\n\nApple silicon, Homebrew:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nApp: **Astrohacker TermSurf** in Applications. On `PATH`: **`ahterm`**,\n**`ahweb`**, **`ahsh`**, and friends. Need a cheatsheet after install? Type\n**`ahhelp`** inside TermSurf.\n\nType the port. Keep the rest of the day in the same window.\n",
            "url": "https://astrohacker.com/blog/2026-07-29-port-shortcut-and-what-termsurf-is",
            "title": "Astrohacker TermSurf v0.1.90: Open Localhost by Port Number",
            "summary": "ahweb opens local servers from a bare port number. Astrohacker TermSurf: terminal, real browser panes, and shell in one window for agentic engineers.",
            "date_modified": "2026-07-29T12:54:59.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-28-since-help-quit-file-open-and-password-plans",
            "content_html": "\nYou open **ahweb**, land on a page with a normal `<input type=\"file\">`, and\nclick it. A real **macOS open panel** appears—owned by the app you launched,\nnot a stuck helper sheet in the Dock. You pick a file. The page gets it. You\ntry **upload folder** on a site that wants a tree; relative paths come through\nthe way desktop Chromium would send them.\n\nThat is not a marketing demo. It is the browser surface inside **Astrohacker\nTermSurf**, finally doing the first half of “use the web like a desktop browser\nin a pane.”\n\nOn [July 27 we wrote about ahhelp, top-right quit, and shell\ndiscovery](/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery)—product\nline roughly **0.1.84–0.1.87**. This post is what landed **after** that window:\nfile **open** that works, an honest list of file transfer still missing, and a\nlocked plan for a password manager that can talk **KeePass KDBX**—without\npretending the cloud product is open for business.\n\n## The short version\n\n- **Done — system file open.** Host-mediated **NSOpenPanel** for single file,\n  multi-select, and **directory upload** (`webkitRelativePath`). Shipped on the\n  product fork pins; monorepo crates **0.1.88**.\n- **In progress — the rest of file transfer.** Finder **drag upload**, **save**\n  / download UX, and **drag download** to disk. Tracked separately; not claimed\n  here.\n- **Planned — password manager.** Vault stays Astrohacker’s model. **KDBX 4.x**\n  import/export is interop for common logins, not “we became KeePass.” Fill and\n  save in Chromium, CLI, and TermSurf apps under **explicit consent**.\n- **Cloud — still building.** Account and vault groundwork continue under the\n  hood. This is **not** a launch, soft-open, or “go create an account” post.\n- **Line — ~0.1.88.** Upgrade the cask when your tap has the chooser pins.\n\nIf you only remember one sentence: **you can pick files and folders for upload\nin TermSurf Chromium now; downloads and drag are next; passwords are a real\nproduct plan, not a finished vault product.**\n\n## File open that behaves like a browser\n\nEmbedded Chromium in a terminal host does not magically own AppKit sheets.\nWhen the engine asked for a file dialog from the wrong process, you got the\nworst of both worlds: no usable panel, or a helper that looked like it owned\nthe machine.\n\nThe path that works:\n\n1. The **engine** parks the chooser request.\n2. **ahterm** (the real host app) runs **NSOpenPanel**.\n3. Chosen paths (or cancel) come back over the **TermSurf** protocol.\n4. The page sees ordinary file-input results.\n\nThat is the same “host mediates, engine does not pretend to be the macOS app”\nidea as the rest of TermSurf—not a second file stack invented for marketing.\n\n### Folders, not only single files\n\nDirectory upload is not “attach one path and hope.” The host walks the tree\n**off the UI thread**, builds the multi-file list with relative paths, and\nfinishes on the UI path the engine expects. We hit a hard fail when the walk\nran on the UI thread (blocking asserts / abort). The fix is boring and correct:\nenumerate where blocking is allowed, then complete.\n\nWhat you can try after upgrade: any site with a file input, multi-select, or\n“upload folder.” If the open panel never appears, or a folder selection freezes\nthe pane, say so—those are regressions against this stretch, not known “maybe\nlater” gaps.\n\n## What is not done yet\n\nClosing file **open** did not close file **transfer**. Still open work:\n\n- **Drag upload** — Finder → page drop target / file input in the pane.\n- **Downloads** — silent Downloads-folder placement *and* system **Save** when\n  the product path needs a save panel, with ordinary completion feedback.\n- **Drag download** — page / browser surface → Finder (or the closest macOS\n  behavior we can ship honestly).\n\nUntil those land, vault **import** is “pick a file” capable; **export/save** and\n“drop the `.kdbx` on the page” are not the full desktop story. We will not\npaper over that with half-claims.\n\n## Why this matters for passwords\n\nWe opened a **Password Manager** epic with a locked product intent.\n\nThe **vault** stays Astrohacker’s design: versioned per-secret ciphertext,\nmulti-tenant cloud, unlock under the user’s keys. It is **not** “the product\nis a KeePass database.” **KeePassXC-class KDBX 4.x** is the **migration and\ninterop** format—import and export common login fields (title, username,\npassword, URL, notes), refuse attachments instead of silently dropping them on\nthe crypto path, accept documented lossy group flatten when needed.\n\nWhere people type passwords:\n\n- **TermSurf Chromium** — fill from vault and save into vault via the\n  password-manager surface (engine hooks TBD by follow-on issues).\n- **CLI** — get/save after appropriate account / unlock.\n- **TermSurf apps** — may request a credential under **explicit user\n  consent**, not ambient full vault dump to every pane.\n\nPasskeys and other non-file secrets may come later. KDBX is the on-ramp and\noff-ramp, not the ceiling.\n\n[Earlier cloud field notes](/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud)\nalready named vault **groundwork** and a real **KDBX 4.x** package path. This\npost is the product plan that sits on top of that foundation—and the reason\nfile open had to land first. Without a working chooser, “import a password\nfile” is fiction.\n\nNone of that means “password manager available now.” It means the next\nsurfaces have a map: transfer the rest of the files, then wire fill/save and\nimport/export where people actually live.\n\n## Cloud: still in the shop\n\nTermSurf remains the interface you run **locally**. The company still builds a\n**cloud backend for the terminal**—accounts, keys, vault, later sync and more.\nThat work is **in progress**.\n\nThis post does **not** open a public onboarding tour, does **not** treat guest\nor signed-in cloud homes as ready, and does **not** ask you to live in a web\naccount to use the terminal you already installed. When the cloud side is ready\nfor ordinary use, we will say so in plain English.\n\n## Upgrade\n\nApple silicon, Homebrew:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nInstall layout is unchanged: **Astrohacker TermSurf** in Applications;\n**`ahterm`**, **`ahweb`**, **`ahsh`**, **`ahcalc`**, **`ahhelp`** (and engine\nhelpers) on `PATH`. File open needs a cask build that includes the **pinned**\nchooser tips—roughly the **0.1.88** monorepo line and whatever revision your\ntap publishes next. Full contract:\n[homebrew docs](https://astrohacker.com/docs) when you need paths and package\nnames.\n\n## Not this post\n\n- Not a re-tour of [ahhelp, quit, and banner discovery](/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery)—those already shipped in the previous field notes.\n- Not the [economic singularity vision essay](/blog/2026-07-27-our-vision-for-the-economic-singularity)—direction, not a ship list.\n- Not “downloads and drag work today.”\n- Not “password manager / KeePass sync available now.”\n- Not a soft-launch map of cloud accounts or OAuth-from-the-CLI as public product.\n- Not “AI marketplace available now.”\n\n## One more thing\n\nKeep the cask current. The last stretch taught the product how to explain\nitself and how to leave cleanly. This stretch teaches the embedded browser how\nto **take files from the Mac** the way users already expect.\n\nDownloads and drag close the loop. The password epic is where that loop pays\noff for secrets—import, export, fill, save—without turning the vault into\nsomeone else’s file format.\n\nIf open panels still fail after upgrade, or a folder upload aborts the engine,\nreport it. The point of shipping every few days is not the version number; it\nis whether a pane still behaves like a tool you trust with a real workday.\n",
            "url": "https://astrohacker.com/blog/2026-07-28-since-help-quit-file-open-and-password-plans",
            "title": "Astrohacker TermSurf v0.1.88: Since Help and Quit: File Open That Works, Transfers Still Coming, and a Real Password Vault Plan",
            "summary": "After ahhelp and chrome quit: host-mediated file open and folder upload in TermSurf Chromium (~0.1.88), downloads and drag still in progress, password-manager epic with KDBX interop—cloud still building, not launched.",
            "date_modified": "2026-07-28T12:23:37.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery",
            "content_html": "\nYou open **Astrohacker TermSurf**, land in **ahsh**, and the banner does not only\nmention Shift+Tab. It tells you to type **ahweb**, type **ahhelp**, and type\n**ah** then Tab. You run **ahhelp**, and a full-pane cheatsheet opens with the\nsame GlyphRain dark as the calculator—host keybinds, browser modes, shell\ndialects, and a short note on what the **TermSurf protocol** actually is. You\nflip to **ahweb**, finish a page, and hit a real **×** in the top-right of the\nchrome instead of hunting **:q**.\n\nNone of that is a new architecture. It is the product explaining itself and\nclosing cleanly after a week of fresher engines and cloud groundwork.\n\nOn [July 26 we wrote about engine pins, shell tips, and the cloud behind\nTermSurf](/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud)—Chromium\n**150**, Ghostty on Zig **0.16**, quieter ahweb chrome, Nu/Reedline on main,\nroughly **0.1.79–0.1.83**, plus honest cloud progress. This post is what landed\n**after** that window for day-to-day use.\n\n## The short version\n\n- **ahhelp** — new TermSurf app: in-pane product help at **`/ahterm`**,\n  **`/ahweb`**, **`/ahsh`** (tabs are real routes). Host defaults and keybinds,\n  ahweb modes, ahsh Nu↔zsh, copy-paste config, Caps Lock tip, and a plain\n  sentence about **webview overlays** (why TermSurf is not stock Ghostty).\n- **ahsh banner** — discovery lines for **ahweb**, **ahhelp**, and **ah** + Tab;\n  command tokens painted **cyan** like Nu’s default external-command style.\n- **ahweb** — **top-right quit (×)** on the nav chrome (width matched to the\n  rest of the strip). **:q** / Ctrl+C still work.\n- **ahcalc** — release packaging actually ships the SPA **`build/client`** so\n  the cask calc is not empty chrome.\n- **Readability** — shared muted text token lifted so secondary copy is not\n  comment-gray across help, calc, and the webapp.\n- **Line** — monorepo product crates roughly **0.1.84–0.1.87**. Upgrade the cask\n  when your tap has the bits you care about.\n\nIf you only remember one sentence: **the stack got fresher last post; this\nstretch makes TermSurf self-explaining and easier to leave without memorizing\ncommands.**\n\n## ahhelp — docs that live in a pane\n\n**ahhelp** is a first-class TermSurf CLI, same family as **ahcalc**: one binary,\nfull-pane web UI, close with × or Esc. It is not a link out to the marketing\nsite. It is product memory for people who already installed the terminal.\n\nThe cheatsheet is three routes, not a single scroll dump:\n\n- **`/ahterm`** (default) — what TermSurf is, host keybinds, stock defaults,\n  config path, pasteable product defaults, Caps Lock → Control, Ghostty docs\n  via `ahweb ghostty.org`.\n- **`/ahweb`** — modes (Browse / Control / Edit / Command), navigation keys,\n  quit paths.\n- **`/ahsh`** — Nu vs zsh, **Shift+Tab**, `SHANNON_MODE`, sample syntax, and\n  `ahweb` pointers to upstream Nu and zsh docs.\n\nThe **What is ahterm?** lead now says the quiet part out loud: TermSurf is\nGhostty-based **plus** the **TermSurf protocol**—CLI apps can load real browser\nengines as **webview overlays inside terminal panes**. That overlay model is\nwhy the product exists and what stock Ghostty does not do. Host splits, shell,\nand pane apps sit under that fact instead of pretending we only re-skinned a\nterminal.\n\nVisual chrome matches the rest of the suite: brand header, glass cards, Glyph\nRain. Muted body text uses the shared brighter secondary token so the long\ncopy is readable.\n\n## Shell intro that names the suite\n\n**ahsh** already said **Shift+Tab** toggles Nu and zsh. New users still need a\nmap of the CLIs on `PATH`.\n\nFull and short banners now include, after the mode line:\n\n- Type **ahweb** to browse the web.\n- Type **ahhelp** for quick help.\n- Type **ah** then **Tab** to see more commands.\n\nThe command tokens use the same cyan as Nu’s default **`shape_external`** so\nthey look like first-token externals on a normal prompt—not green “success”\nnoise.\n\n## ahweb — quit without the command bar\n\nBrowse and Control still own most of the story. The missing piece for muscle\nmemory from every other app was a **visible quit** control.\n\nahweb now has a **×** on the top-right of the chrome, sized like the rest of\nthe nav strip. Prefer **:q** or Ctrl+C if you live in the command bar; the\nbutton is for everyone else (and for the days you forget the colon).\n\n## ahcalc packaging (one honest fix)\n\nahcalc was already the scientific calculator pane. A release-stage gap meant\nsome packaged builds could miss the SPA client tree. The stage now ships\n**`build/client`** with the binary so **Homebrew calc** matches what developers\nrun from a full tree. If calc looked broken after install, upgrade and try\nagain—not a new product, a payload that finally matches the app.\n\n## Upgrade\n\nApple silicon, Homebrew:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nInstall layout stays the same: **Astrohacker TermSurf** in Applications;\n**`ahterm`**, **`ahweb`**, **`ahsh`**, **`ahcalc`**, **`ahhelp`** (and engine\nhelpers) on `PATH`. Full contract: [homebrew docs](https://astrohacker.com/docs)\nwhen you need paths and package names.\n\n## Not this post\n\n- Not the [economic singularity vision essay](/blog/2026-07-27-our-vision-for-the-economic-singularity)—that is direction, not a ship list.\n- Not a soft-launch map of cloud accounts, OAuth-from-the-CLI, or bookmarks\n  sync.\n- Not a tmux multi-webview architecture diary (we assessed it; it is not a\n  user feature today).\n- Not “AI marketplace available now.”\n\n## One more thing\n\nKeep the cask current. The last post refreshed engines and shell pins under\nyour feet. This stretch puts **help, discovery, and quit** where your hands\nalready are—pane, banner, chrome.\n\nIf **ahhelp** is missing a binding you use every day, or the banner still\nsends you nowhere useful, say so. The point of shipping every few days is not\nthe version number; it is whether a new pane still feels like a tool you can\nlearn without leaving the terminal.\n",
            "url": "https://astrohacker.com/blog/2026-07-27-since-engine-pins-help-quit-and-shell-discovery",
            "title": "Since Engine Pins: Help in a Pane, Quit in Chrome, and a Shell That Points You",
            "summary": "After the pin-and-cloud post: ahhelp (in-pane product docs), ahweb’s top-right quit, ahsh banner discovery, ahcalc SPA packaging fixed—product line ~0.1.84–0.1.87.",
            "date_modified": "2026-07-27T11:45:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-27-our-vision-for-the-economic-singularity",
            "content_html": "\nMost of the economy still looks like **person ↔ person**. You buy from a shopkeeper, hire a contractor, pay a freelancers. On the web and the phone, the counterparty is often a **corporation’s computer**—you still decide and pay, but the other side is software running for a company.\n\nWe are only in the early innings of putting **AI agents** inside businesses. They draft, search, call APIs, open tickets. That is real, and it is still mostly *tools in human hands*.\n\nWhat comes next is not “smarter autocomplete.” It is agents that do not only *use* tools, but **spend**—endowed with a **budget**, sent into the world to accomplish a goal, and allowed to pay for what the goal requires. That is the last mile of agent tooling. Once trade among agents is normal, markets do not grow linearly. They explode.\n\nWe call the threshold where that happens the **economic singularity**: the moment when the **AI ↔ AI** (and agent-mediated) economy **outgrows** the human ↔ human economy—and even the familiar human ↔ corporation economy. Not as a doomsday slogan. As a claim about **scale of trade and wealth creation**.\n\nAstrohacker’s vision is simple to say and hard to build:\n\n**Empower our users to create and own a piece of the economic singularity.**\n\n## The economy as it is\n\nFor most of history, commerce assumed humans at both ends of the deal—or a human on one end and an institution on the other. Corporations automated the *storefront* and the *ledger*. They did not put an autonomous economic actor on your side of the table with a purse and a mandate.\n\nAgents today are closer to interns with a browser: powerful, cheap, unreliable without supervision, and almost never allowed to open the company card without a human in the loop. That is the right default *for now*. It is not the end state.\n\n## Agents with tools are not enough\n\nGive an agent a shell, a browser, a calendar, a CRM. Useful. Still incomplete.\n\nThe missing tool is **money with a policy**. A budget is not a metaphor. It is a constrained account the agent can draw on to:\n\n- buy API calls, compute, data, or services;\n- pay other agents for work;\n- settle obligations when a goal requires a real-world (or real-internet) transaction.\n\nWithout a budget, an agent is a brilliant tourist. With a budget, it is a participant. That is the **final stage of agent tooling**: not one more plugin, but **economic agency**.\n\n## Why that becomes a singularity\n\nMarkets compound. When agents can hire other agents, specialize, and re-spend, the number of transactions is no longer capped by human attention or 9-to-5 staffing. Specialization deepens. Latency drops. Entire categories of trade that were not worth a human’s time become viable at machine scale.\n\nWe are not claiming that day is next Tuesday. We are claiming the direction is obvious once budgets are normal—and that **whoever owns productive capacity in that economy** owns a stake in historic wealth creation. Watching is not a strategy. **Creating** is.\n\n## How you own a piece: you create it\n\nYou do not get a claim on the economic singularity by holding the right ETF ticker invented after the fact. You own a piece by **running economically productive agents**—a team that trades with other agents (and with people and services) to create value under your goals and constraints.\n\nThat is the product promise underneath the phrase:\n\n- **You** set goals, risk, and budgets.\n- **Your agents** execute, spend within policy, and trade.\n- **The network** of other agents and markets is where value is discovered.\n\nAstrohacker exists so that path is not reserved for a handful of labs or platforms. We want **users**—builders, operators, small teams—to be able to field that team and keep the upside.\n\n## What we are building\n\nTwo layers, same idea as email:\n\n| Layer | Email analogy | Agent economy |\n| --- | --- | --- |\n| **Protocols** | SMTP and friends—open rails anyone can implement | **KeyPears** and related protocols: identity, secrets, and trade primitives that extend the internet for agents |\n| **Marketplace / product** | Gmail—the place people actually gather | The **Astrohacker webapp and marketplace**, plus **TermSurf** as the on-device surface where work already lives |\n\nIn short: **Astrohacker is to the agent economy what Gmail was to email**—not only a brand, but a **usable square on top of protocols** that define how the network talks.\n\nConcretely, the arc looks like this:\n\n1. **On-device power** — [Astrohacker TermSurf](/): real terminal, real browser engines in panes, local-first control. The place you live while agents and tools grow up around you.\n2. **Cloud backbone** — the company webapp as account, identity, vault, and eventually the home for agents and marketplaces. Foundation work is in progress; it is not a soft-open “agent mall” yet.\n3. **Agents with tools** — embed AI agents in the webapp with tools they can call. Direction, not a feature checklist of what you can click today.\n4. **Budgets** — a first-class **cryptocurrency (and later broader) budget** an agent can spend to pursue a goal under your rules. That is the economic hinge.\n5. **Marketplace + economy** — a place people and agents gather to trade, on rails that are not a single closed silo.\n\nWe are building **both** the marketplace **and** the economic stack—not a brochure site that points at someone else’s rails.\n\n## Honesty about the timeline\n\nThis post is **vision**, not a ship announcement.\n\n- **Shipped and shipping:** downloadable TermSurf, the browser-in-terminal product line, ongoing cloud app work (accounts, keys, vault groundwork, deploy path). See recent engineering posts on this blog for what actually landed.\n- **Direction, not “available now”:** full agent teams with spendable budgets, a liquid AI↔AI marketplace, English shell as the default interface to that world, hosted model marketplace economics. We will not pretend those are installable features until they are.\n\nThe economic singularity is a **north star**. We build toward it in public, product by product.\n\n## The nutshell\n\nThe economy today is still mostly humans and human institutions. Agents are arriving with tools. The next leap is agents with **budgets**. When AI↔AI trade outgrows human-scale commerce, that is the **economic singularity**.\n\n**You own a piece by creating it**—fielding agents that work and trade under your control.\n\n**Astrohacker** is building the **protocols** (KeyPears and friends) and the **marketplace** (webapp + terminal surface) so our users can do exactly that: **create and own a piece of the economic singularity.**\n\nIf you want the product that exists today, start with [TermSurf](/) and the [blog](/blog). If you want the long game, this is it.\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-07-27-our-vision-for-the-economic-singularity",
            "title": "Our Vision for the Economic Singularity",
            "summary": "Human trade built today’s economy. Agents with tools and budgets will build the next. How Astrohacker aims to create the rails—and let users own a piece.",
            "date_modified": "2026-07-27T10:15:52.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud",
            "content_html": "\nYou upgrade **Astrohacker TermSurf**, open a pane, click into the URL field, and\nthe caret lands where you meant. The nav chrome does not flash a second color\nunder the pointer. The shell under it is still **ahsh**, still Nu-powered, on a\nnewer upstream tip. None of that is a reorg. It is the same product, a few days\nof pin and host work after the last feel-good Chromium week.\n\nOn [July 22 we wrote about hard refresh, flick scroll, and video](/blog/2026-07-22-hard-refresh-flick-scroll-and-video)—the\nday-to-day wins after [Chromium only—for now](/blog/2026-07-21-chromium-only-for-now).\nThat post closed around product line **~0.1.69–0.1.78**. This one is what landed\n**after** that window: fresher engines and shell pins you can install, quieter\nbrowser chrome, and honest progress on the **cloud app** that will back the\nterminal—not a launch, not a soft-open tour.\n\n## The short version\n\n**Downloadable TermSurf family**\n\n- **Chromium** product pin moved to Electron-stable chrome **150.0.7871.129**.\n- **Ghostty** host advanced to current **main**, on **Zig 0.16**, with TermSurf\n  IPC/runtime hardening so the host still talks cleanly to the engine.\n- **ahweb** — no hover paint on the nav strip; Control-mode **URL click inserts\n  at the cursor** instead of only “jumping” the field.\n- **ahsh** — **Nushell** and **Reedline** re-pinned to upstream **main** (path\n  coupled); product shell patches rebased (PATH union / lazy env surface kept).\n- **Line** — monorepo product crates moved through roughly **0.1.79–0.1.83**.\n  Upgrade the cask when your tap has the bits you care about.\n\n**Cloud webapp (in development)**\n\n- Same company arc: **on-device TermSurf**, **cloud backend for the terminal**.\n- Already real in code and deploy path: account/settings, identity **keys**,\n  **password vault** groundwork (including **KDBX 4.x**), shared UI, oRPC data\n  plane, AWS deploy.\n- **Not** pretend-shipped: bookmarks sync, polished password sync product,\n  wallet, AI agent management and marketplace. Those are the destination.\n\nIf you only remember one sentence: **keep upgrading TermSurf from the tap; the\nengines and shell got newer under your feet, and the cloud layer is being built\nto meet the terminal—not replace it with a web demo.**\n\n## What you can install today\n\n### Fresher Chromium\n\nThe shipped engine pin is no longer stuck on an older patch of the same Electron\n43 line. Product Chromium sits on **150.0.7871.129** (Electron stable chrome for\nthat cadence). Same family as the Chromium-only bet: one engine, security and\nmedia path we actually ship—not tip-of-tree archaeology.\n\n### Host and IPC (Ghostty / TermSurf)\n\nThe host terminal is not a frozen fork. Ghostty is on a current **main** tip\nwith the product patch series rebased, toolchain at **Zig 0.16**. Follow-up work\nhardened TermSurf runtime details that only show up when the host and engine\nhandshake—socket env for children, interrupt-safe I/O, Darwin sockaddr details.\nYou should not need to care about those names; you should get a host that still\nstarts panes after the pin jump.\n\n### ahweb chrome that stays out of the way\n\nTwo small Control-mode / browse-chrome changes:\n\n- **No hover paint** on the nav strip—less visual noise when the pointer\n  crosses buttons.\n- **URL click → insert at cursor** when you are editing the bar, so a click\n  behaves like an editor, not only like “select everything and hope.”\n\n### Shell on newer Nu\n\n**ahsh** still means Astrohacker Shell: Nu under the product CLI, Reedline as\nthe line editor, path-pinned forks. Both **Nushell** and **Reedline** moved to\nupstream **main** tips in one pass so the path deps stay coherent. Product\nbehavior we care about (lazy traditional shell env, Nu-first PATH union so tools\nlike `cargo` do not vanish) was rebased with the tip—not thrown out for a clean\nmerge.\n\n### Version line\n\nAfter the last post’s **~0.1.69–0.1.78** window, the monorepo product crates\nwalked **0.1.79** through **0.1.83**. Exact cask revision is whatever you\ninstalled last; the story is “several release bumps of host/engine/shell\npins,” not one magic number that fixes everything.\n\n## Upgrade\n\nApple silicon, Homebrew:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nInstall layout and names stay the same: **Astrohacker TermSurf** in\nApplications, **`ahterm` / `ahweb` / `ahsh`** (and friends) on `PATH`. Details:\n[docs/homebrew](https://astrohacker.com/docs) when you need the full contract.\n\n## The cloud app—progress, not a product tour\n\nTermSurf is the interface you run locally. The **webapp** is the cloud side of\nthe same product: account, sync, keys, vault, and later wallet and **AI agent\nmanagement / marketplace**. That is the plan. It is **not** “go open a secret\nURL and pretend the backend launched.”\n\nWhat has been built hard enough to name without lying:\n\n- **Account and settings** — change password, delete account with real\n  confirmation, session-aware shell chrome.\n- **Identity keys** — KeyPears-shaped list/detail, rotation and re-encrypt\n  flows, hybrid post-quantum framing where the product already claims it.\n- **Password vault foundation** — lock/unlock, secret entries, authorization\n  that does not trust the client on a good day; plus a real **KDBX 4.x**\n  package path so import/export is not a toy JSON dump.\n- **UI system** — shared kit and dialog shell so modals are one product, not\n  five slightly different blurs.\n- **Data plane and ops** — oRPC under `/api`, models that loaders can own,\n  AWS deploy path, blog and app content that actually ships in the image.\n\nWhat is **not** ready for “it works for everyone” language:\n\n- Bookmarks and password **sync** as a finished product surface  \n- Cryptocurrency **wallet** as a shipping feature  \n- **AI agent management** and an **agent marketplace** as public UX  \n\nThose are why the backend exists. They are not today’s install checklist.\n\nWhen the cloud side is ready for you, we will say so in plain English—with a\nnormal entry path, not a scavenger hunt.\n\n## Not this post\n\n- Not a Chromium tip-of-tree diary.  \n- Not a soft-launch map of guest vs signed-in homes.  \n- Not “AI marketplace available now.”  \n- Not a promise that every experimental route is public product.\n\n## One more thing\n\nKeep the cask current. The last post fixed **feel** on Chromium-only panes.\nThis stretch fixed **freshness** of the stack under those panes—and put real\nmass behind the cloud backend that TermSurf will plug into.\n\nIf something still feels wrong after upgrade, say so. The point of shipping\nevery few days is not the version number; it is whether the terminal still\nbehaves like a tool you trust with an open day.\n",
            "url": "https://astrohacker.com/blog/2026-07-26-since-hard-refresh-engines-shell-and-cloud",
            "title": "Since Hard Refresh: Engine Pins, Shell Tips, and the Cloud Behind TermSurf",
            "summary": "After the Chromium-only feel fixes: fresher Chromium and Ghostty pins, cleaner ahweb chrome, Nu on main for ahsh, product line ~0.1.83—and real progress on the cloud backend for the terminal.",
            "date_modified": "2026-07-26T20:06:30.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-22-hard-refresh-flick-scroll-and-video",
            "content_html": "\nYou open a long page in an **Astrohacker TermSurf** Chromium pane, flick the\ntrackpad, and the document **keeps coasting** after your fingers leave the\nglass. You hit **Cmd+Shift+R** (or type **`:rh`** in the command bar) and the\npane reloads **past the cache**. You open a video on X and it **actually\nplays**.\n\nThat is the Chromium-only bet paying rent: one engine, finished enough to feel\nordinary.\n\nOn [July 21 we said Chromium only—for now](/blog/2026-07-21-chromium-only-for-now):\nWebKit and Ladybird off the active product surface so one browser path can\nmature. This post is what landed for **daily use** after that cut—not the\ninvestor deck, not website tooling, not engine archaeology.\n\n## The short version\n\n- **Hard refresh** — ignore-cache reload: **Cmd+Shift+R** / **Shift+R**, and\n  Control-mode **`:refresh hard`** / **`:rh`**. Soft stays **Cmd+R**, toolbar\n  click, **`:refresh`** / **`:r`**.\n- **Trackpad flick** — two-finger inertia (coast) works in Chromium browse\n  panes.\n- **Media** — proprietary codecs (Chrome branding path) so sites like **X** can\n  play H.264 video in-pane.\n- **Shell** — **lazy zsh** for a fast `ahsh` prompt; then a **Nu-first PATH**\n  merge so zsh’s environment does not erase tools like `cargo`.\n- **Housekeeping** — TermSurf **XDG / state paths** under the product name;\n  pane content **corner clip** so overflow does not fleck the chrome.\n- **Line** — monorepo product crates moved through roughly **0.1.69–0.1.78**;\n  upgrade the cask when your tap has the bits you care about.\n\nIf you only remember one sentence: **Chromium-only bought us room to fix\nreload, scroll feel, video, and shell startup—the stuff you touch every hour.**\n\n## Hard refresh (cache-bust without leaving the pane)\n\nBefore this window, soft reload was easy and hard reload was not a trustworthy\nproduct story. Soft still means normal reload. Hard means **ignore HTTP\ncache**—the engine path is Chromium\n`ReloadType::BYPASSING_CACHE`, not a soft `reload()` wearing a costume.\n\n**Soft**\n\n- **Cmd+R** (Command+R, no Shift)\n- Toolbar refresh button\n- Command bar: **`:refresh`** or **`:r`**\n\n**Hard**\n\n- **Cmd+Shift+R** / **Shift+R** (in Control / Browse when keys reach `ahweb`)\n- Command bar: **`:refresh hard`** or **`:rh`**\n\n**What we deliberately do not promise:** Shift+click on the toolbar as hard\nrefresh. Terminals (including our host) often treat Shift+mouse as selection /\n“escape mouse grab” and **do not deliver Shift on the click** the way a\nbrowser chrome does. Units that faked Shift on mouse-up were green; the\nproduct was not. Hard reload lives on **keyboard and commands**, where\nmodifiers actually arrive.\n\n## Trackpad flick / inertia\n\nDirect scroll while fingers stay on the pad already moved the page. A\n**flick**—lift and coast—did not. That is the difference between a remote\nwebview that only applies deltas and one that preserves a Mac **phase /\nmomentum** sequence after finger-up.\n\nWe filled more wheel fields first; that alone was not enough. Tracing showed\nmomentum can reach the engine; the remaining fix was routing synthetic wheels\nthrough Chromium’s Mac **phase-handler** path (delayed physical `phase=ended`,\nsame family as Chrome’s `RouteOrProcessWheelEvent`) instead of a bare route\nthat could kill the fling at the phase boundary.\n\nOperator check: long page, two-finger flick, **coast**. That closed the issue.\n\n## Video in `ahweb` (X and friends)\n\nSome sites never play without **proprietary codecs**. Our Chromium product\nbuild was too thin for that world: no H.264 where the page expects it, so X\nand similar media stayed silent or broken.\n\nWe enabled the product **proprietary codecs + Chrome ffmpeg branding** path\nused for real playback. After the rebuild, **X video plays** in a TermSurf\nChromium pane. That is the user-facing bar—not a codec laundry list.\n\n## Faster shell, correct environment\n\n**Lazy zsh.** Spawning a full zsh for every alt-shell handshake blocked a\nsnappy `ahsh` start. Lazy startup lets the prompt arrive while zsh is not\nholding the door. Shift+Tab to zsh still exists when you want it; the greeting\ndoes not wait on a serial cold start.\n\n**Env after lazy.** Speed without cargo is a trap. The follow-on fix keeps\n**zsh as the base environment**, then merges with a **Nu-first PATH** (Nu\nentries first, zsh entries deduped after) so tools you installed under zsh\nstill resolve and Nu’s own path additions are not clobbered.\n\nNet: quick start, then an environment that still runs real work.\n\n## Paths and pixels\n\n**TermSurf XDG / state naming.** Config and state folders follow the product\nname (**termsurf**), not a leftover “terminal” tree. If you had old paths, look\nfor the new tree after upgrade—same product, honest home on disk.\n\n**Pane corner clip.** Web content no longer peeks past rounded pane corners as\na little fleck of overflow. Small visual, large “this is intentional chrome”\nenergy.\n\n## Versions\n\nProduct crates in the monorepo stepped through roughly **0.1.69** to\n**0.1.78** in this window. Public cask version may lag a commit or two—when\nyou upgrade, match the notes above to what your install actually contains\n(`ahweb` hard refresh, coast, codecs, `ahsh` startup).\n\n## What we did not cover here\n\n- Investor deck / fundraising copy\n- Website dev-server plumbing\n- KeyPears or other non-TermSurf experiments\n\nThose matter; they are not “open a pane and work.”\n\n## Still Chromium only\n\nThe [previous post](/blog/2026-07-21-chromium-only-for-now) still holds:\n**one** shipped browser engine. This work is what “focus” is for—reload that\nmatches developer muscle memory, scroll that matches a Mac trackpad, media\nthat matches the modern web, shell that starts fast without lying about PATH.\n\nInstall or upgrade when ready:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nThen try three things: **flick** a long page, **hard refresh** with\n**Cmd+Shift+R** or **`:rh`**, and open a **video on X**. If something still\nfeels wrong, that is useful signal—send it.\n",
            "url": "https://astrohacker.com/blog/2026-07-22-hard-refresh-flick-scroll-and-video",
            "title": "Hard Refresh, Flick Scroll, and Video: What’s New After Chromium-Only",
            "summary": "Since the Chromium-only cut: ignore-cache reload, trackpad inertia in panes, proprietary media for sites like X, faster lazy zsh, saner env merge, and TermSurf path cleanup.",
            "date_modified": "2026-07-22T21:30:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-21-chromium-only-for-now",
            "content_html": "\nYou open `https://astrohacker.com` in a pane, put **Astrohacker TermSurf** into\nnative fullscreen, and the glyph rain keeps moving. Links still navigate. The\npage is not a frozen screenshot of yesterday’s Space.\n\nThat is the Chromium path working the way a hosted browser should.\n\nWhat you will **not** find in a current install is a second or third shipped\nengine helper. No `ah-webkitd`. No Ladybird. No “reserved Gecko” story on the\nproduct surface. **One** browser engine ships: **Chromium**.\n\nOn [July 20 we field-noted 0.1.47 through 0.1.60](/blog/2026-07-20-astrohacker-0-1-60)—\nTermSurf by name, Browse first, `ahcalc`, focus that stays local. This post is\nwhat happened **after** that line: a hard day of engine work, then an honest\ncut.\n\n## The short version\n\n- **Shipped browser:** **Chromium only** — panes, Homebrew package, warmups,\n  docs, and marketing product copy.\n- **Archived (not erased):** **WebKit** and **Ladybird** leave the active\n  product. Patch history, closed issues, and old blog posts stay. They can\n  return under **new** issues later.\n- **Gecko residual scrubbed** — it was never a public ship engine; we stopped\n  advertising it as reserved future furniture.\n- **Chromium maturity first** — fullscreen / Mission Control freeze fixed for\n  live webviews (helpers join the host Space; we did not ship a permanent\n  “never background anything” hammer).\n- **We tried before we cut** — WebKit got a live compositor path (rain that\n  actually animates). Ladybird still painted black after real pin work. Cost\n  stayed high; daily use stayed Chromium.\n- **Also this window:** `ahcalc` no longer dies on Bun’s compiled `/$bunfs/…`\n  argv; browser chrome labels follow a **naming convention** instead of a\n  hard-coded engine table.\n- **Line** — monorepo product crates through **0.1.68**; upgrade the cask when\n  your tap has the Chromium-only package.\n\nIf you only remember one sentence: **we proved multi-engine can work; now we\nship one engine well so it can become boringly reliable—and invite the others\nback when that job is done.**\n\n## Why remove WebKit and Ladybird\n\nNot because multi-engine was a fantasy. Astrohacker TermSurf already ran\n**real** engines in terminal panes. Chromium, WebKit, and Ladybird were not\nslideware. Gecko work produced scaffold and hard lessons\n([why Gecko is the hard one](/blog/2026-07-12-why-gecko-is-the-hard-one)) without\na public ship contract.\n\nThe problem is **attention**.\n\nEach engine is a fork, a helper, a presentation path, packaging, warmups,\ndocs, and a long tail of input and paint special cases. WebKit alone ate live\ncompositor work, hover paths, and build-shore qualification. Ladybird ate pin\nisolation and still showed a **black pane** that navigated and titled correctly\nwhile pixels refused to show. Chromium, the engine we actually live in for\nproduct development and most web-developer testing, still had gaps—like\nwebview freeze after the host window changed Space or entered native\nfullscreen.\n\nSpreading effort across three (or four) engines leaves **none** of them at\n“this is finished.” That is a bad trade for an early product.\n\nSo we made a deliberate cut:\n\n- **Park** WebKit and Ladybird on the active product surface.\n- **Focus** on Chromium until it is mature enough that “open a URL in a pane”\n  stops being a research project.\n- **Keep the door open** — multi-engine is architecture we already exercised.\n  When Chromium is the solid default, other engines can earn a new issue and a\n  new ship contract. History under `patches/` and the issue archive is how we\n  reconstruct them—not a half-dead helper in every cask forever.\n\nNot “we hate WebKit.” Not “Ladybird failed forever.” Not “multi-engine is\ndead.”\n\n**It is: one mature engine beats three half-done ones—for now.**\n\n## What we did before we cut\n\nRemoval is easier to trust if you see the day we spent **trying**.\n\n### Fullscreen that stays live (Chromium)\n\nWith the marketing site open, entering **native fullscreen** or moving the\nhost to another Mission Control desktop could freeze the page: rain stopped,\nclicks died, the TUI stayed fine. Helpers had been left on the **previous**\nSpace while the host moved.\n\nWe fixed that on the Chromium path by **co-locating** helper source windows with\nthe host (or joining Spaces for non-visible helpers)—not by leaving a permanent\nprocess-wide “disable occlusion backgrounding” flag in product spawn. Windowed\nbrowsing, resize, focus, and cleanup stay ordinary. Fullscreen should feel\nlike the same browser, bigger.\n\nThat is the kind of defect we want headroom to chase next: presentation,\nSpaces, polish, packaging—**one** stack at a time.\n\n### WebKit: live rain, still expensive\n\nWebKit’s old presentation path was snapshot-backed: capture bitmaps on discrete\nevents, ship those to the host. CSS animation and hover did not keep the pane\nalive. We pushed a **live compositor** path so glyph rain could run for a full\nminute without click-to-repaint theater, and we chased hover authority after\nthat.\n\nThose issues closed as real progress. They also proved the bill: fork builds,\ncompositor seams, input special cases, two build shores, continuous tax. The\noperator disposition was blunt: WebKit is not the day-to-day engine; Chromium\nis. After Ladybird left, keeping WebKit as a second full ship contract was\nstill too much surface for MVP.\n\nSo WebKit left the **active** product the same way Ladybird did: out of\nHomebrew and packaging, out of living docs and marketing claims, live fork no\nlonger required. **Historical** patch series and issues remain. Hover and other\nWebKit product work are out of scope unless a future issue reopens the engine.\n\n### Ladybird: black pane, then out\n\nLadybird still reported title, URL, and engine identity while painting a large\n**black** rectangle—presentation, not “failed to spawn.” We offered render\nservices more uniformly, isolated pin hypotheses, and closed the paint issue\nfor **MVP without a full pixel fix**: multi-engine was already proven by\nChromium + WebKit; Ladybird was not required to ship.\n\nThen we removed Ladybird from the active product surface entirely—release path,\npin, code, website—while keeping historical archives. A cask/tarball mismatch\non the way out taught the usual packaging lesson: formula body and archive\ncontents must stay in lockstep. The install story is Chromium-only now, on\npurpose.\n\n### Gecko residual\n\nGecko was never in the Homebrew ship set. After WebKit and Ladybird left,\nliving docs and crates still whispered “reserved” or kept scaffold around.\nThat confuses a Chromium-only product. We scrubbed the **active** residual and\nleft the historical narrative alone. No claim that Gecko “ships someday” until\nsomeone opens a real issue and finishes the work.\n\n## Small product fixes in the same window\n\nEngine cuts were the headline. Two smaller changes still matter when you\nupgrade:\n\n- **`ahcalc`** — the compiled one-binary client was rejecting Bun’s synthetic\n  `/$bunfs/root/ahcalc` argv entry as a user argument. Normal no-flag launch\n  works again; real flags and `--server` still mean what they meant.\n- **Browser labels** — pane chrome no longer depends on a hard-coded map of\n  engine families. Helpers named like `{prefix}-{stem}d` display as `{stem}`\n  (`ah-chromiumd` → `chromium`). Selection and routing are unchanged. When\n  another engine returns, labeling does not require rewriting a private\n  allowlist first.\n\n## What still ships\n\nSame install story, narrower engine list:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nOr:\n\n```sh\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nApp: **`/Applications/Astrohacker TermSurf.app`**. On PATH you still want\n**`ahterm`**, **`ahsh`**, **`ahweb`**, **`ah-chromiumd`**, and **`ahcalc`**.\nYou should **not** expect WebKit or Ladybird helpers in a current package.\n\nStill one cask. Still **Apple silicon**. Still **The Agentic Hacker’s\nTerminal** as slogan—even when the app on disk is TermSurf and the browser\ninside it is Chromium.\n\nWorth five minutes after upgrade:\n\n1. `ahweb https://astrohacker.com` — type into the page (Browse-first from\n   0.1.60 still applies).\n2. Enter native fullscreen — rain should keep moving; a link click should\n   navigate.\n3. Run **`ahcalc`** with no flags — it should start the client path, not die on\n   a bunfs path argument.\n4. Confirm you are not hunting for `ah-webkitd` or Ladybird in the cask.\n\nProtocol and product docs: [How TermSurf Talks](/blog/2026-07-19-how-termsurf-talks),\n[/docs](/docs), [Chromium docs](/docs/chromium). Prior field notes:\n[0.1.60](/blog/2026-07-20-astrohacker-0-1-60).\n\n## What this does not change\n\n- **TermSurf** as the wire language and multi-pane host model.\n- Historical posts and issues that named WebKit, Ladybird, or Gecko—those are\n  the record, not active claims.\n- Willingness to run **more than one** engine again when the primary path is\n  mature enough that second engines are a choice, not a distraction.\n\nUpgrade. Use Chromium panes hard. File Chromium bugs. When the default browser\npath is boringly solid, other engines can come back the right way: a new issue,\na real ship contract, and a product that already works with one engine at\nfull strength.\n",
            "url": "https://astrohacker.com/blog/2026-07-21-chromium-only-for-now",
            "title": "Chromium Only (For Now): Why We Shelved WebKit and Ladybird",
            "summary": "After 0.1.60 we fixed Chromium fullscreen, tried harder on WebKit and Ladybird, then archived them so one engine can finish—and come back later.",
            "date_modified": "2026-07-21T23:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-20-astrohacker-0-1-60",
            "content_html": "\nYou open the Dock and the app no longer says **Terminal**. The bundle is\n**Astrohacker TermSurf**. The title bar falls back to a **surfer**, not a\nghost. You type `ahweb example.com`, hit Enter once, and keys go to the\n**page**—not into a Control mode that asked for a second Enter before the\nbrowser felt real.\n\nThat is the line from **0.1.47 through 0.1.60**.\n\nOn [July 18 we field-noted rounded panes and the welcome splash](/blog/2026-07-18-astrohacker-0-1-47).\nOn [July 19 we walked the TermSurf protocol](/blog/2026-07-19-how-termsurf-talks)—\nhost, client, engine helpers, protobuf on local sockets. This post is the\n**user-facing delta** after those: what you install, what you click, what\nfocus does when you move between splits.\n\nStill one cask. Still **Apple silicon**. Still **The Agentic Hacker’s\nTerminal** as slogan—even when the app name on disk is TermSurf.\n\n## The short version\n\n- **Product name:** **Astrohacker TermSurf.app** in\n  `/Applications` (cask token still `astrohacker`; CLI still `ahterm`).\n- **Dock icon:** **Astrohacker monogram** (AH). The wave mark was tried for the\n  host icon and then put back down—product _name_ stayed TermSurf.\n- **Title defaults:** empty / fallback chrome uses **🏄** and **🏄 TermSurf**,\n  not Ghostty’s ghost.\n- **`ahweb` starts in Browse** — page first; Escape still reaches Control.\n- **`ahcalc`** — scientific calculator as a **TermSurf app** (full-pane web\n  UI), **one binary** for client and server roles, wired into the Homebrew\n  package story.\n- **Split focus stays local** — spatial up/down/left/right prefer the straight\n  neighbor band; MRU no longer diagonal-jumps when a real orthogonal pane\n  exists.\n- **Public site** — live marketing surface kept in step (docs/product naming,\n  welcome, polish). Stack work is ours; you care that [astrohacker.com](https://astrohacker.com)\n  still looks like the product.\n- **Line** — **0.1.50 … 0.1.60** on the usual tap.\n\nIf you only remember one sentence: **upgrade, open a URL without a second\nEnter, split a 2×2 and move with the arrows, and run `ahcalc` if you want a\ncalculator that lives in a pane instead of another floating window.**\n\n## The app is called Astrohacker TermSurf\n\nFor a long time the install said **Astrohacker Terminal** while the _protocol_\nthat makes browser panes work was already **TermSurf**. That split was\naccurate for engineers and muddy for everyone else.\n\nWe renamed the **desktop product**:\n\n- Bundle: **`Astrohacker TermSurf.app`**\n- Install path: **`/Applications/Astrohacker TermSurf.app`**\n- Docs and product copy that still meant “the host you launch” follow the new\n  name\n\nWhat we **kept** on purpose:\n\n- Homebrew cask **`astrohacker`**\n- PATH launcher **`ahterm`**\n- Protocol name **TermSurf** (`termsurf.proto`, helpers, `TERMSURF_*` where they\n  already lived)\n\n**TermSurf** is still the wire language. **Astrohacker TermSurf** is the\nwindow. If that sentence feels redundant, good—it is supposed to collapse the\nold “Terminal vs protocol” gap, not invent a second SKU.\n\n### Monogram on the Dock, surfer in the title\n\nIcon work went in two honest steps.\n\n1. First we put the **TermSurf product mark** (wave) on the host AppIcon so the\n   rename had a face.\n2. Then we **restored the Astrohacker monogram** as the Dock / Finder icon.\n   The company mark owns the tile; the product name owns the string.\n\nTitle bar defaults were a separate leftover: empty surfaces and fallback titles\nstill smelled like **Ghostty** (ghost emoji, “Ghostty” wording). Defaults now\nuse the **surfer**—**🏄** alone, or **🏄 TermSurf** for the short branded\ntitle. That is chrome text, not a second icon pipeline.\n\n## Browse opens first\n\n`ahweb` used to leave you in **Control** mode after launch. Opening a URL from\nthe shell meant: Enter to start the client, then **another** Enter (or mode\nswitch) before typing into the page felt normal. Fine for power users who live\nin pane chords. Wrong for “I just opened google.com.”\n\n**Browse is the default** on a normal launch. Keys go toward the page / overlay\npath. The host still keeps a **Browse chrome allowlist** so the split and tab\nbindings you need as a multi-pane product do not vanish the moment a document\nhas focus.\n\n**Escape** still reaches Control. We did not delete the hatch. We stopped\nmaking the hatch the front door.\n\n## `ahcalc`: a calculator that is a TermSurf app\n\nThis line ships a real **TermSurf app** in the product story: **`ahcalc`**, a\nscientific calculator with a full-pane web UI.\n\nShape that matters to you:\n\n- **One on-disk binary** — client and server roles from the same file (no\n  sibling `ahcalc-server` you have to keep next to it).\n- **Local only** — the calculator UI is served on **loopback**; a second invoke\n  finds the running server over a **Unix domain socket** and opens or reuses a\n  pane.\n- **No host port registry** inside `ahterm` — the app owns its process model;\n  the host owns panes and the protocol.\n\nThis is not a second IDE. It is not “English shell.” It is a calculator that\nuses the same browser-pane machinery as `ahweb`, so the product is allowed to\ngrow apps without inventing a different windowing system.\n\nHomebrew packaging stages **`ahcalc`** with the cask contents (binary + static\npayload). If your install is current, `ahcalc` should be on PATH with the rest\nof the bundle. If something is missing after upgrade, the cask is the first\nthing to reinstall—not a random npm global.\n\n## Focus that does not teleport\n\nWe already fixed **split focus memory** so nested layouts remember where you\nwere when you re-enter a region. The next bug was subtler: **temporal MRU**\ncould yank you **diagonally** on a pure arrow move when a straight neighbor\nexisted.\n\nCanonical 2×2:\n\n```text\n TL | TR\n----+----\n BL | BR\n```\n\nFocus **BR**, move **up**. You should land on **TR**—not **TL** because TL was\n“recent.” Same idea for left/right along a row.\n\n**Secondary-axis locality** means: after a pure orthogonal move, prefer panes\nin the same **row** (for left/right) or **column** (for up/down) before MRU\ngets a vote. Nested re-entry memory from the earlier fix still works. The\narrows should feel spatial again.\n\n## The public front door\n\nThe install still points people at **astrohacker.com**. In this window we kept\nthe marketing surface aligned with the product rename (docs call the host\n**Astrohacker TermSurf**, welcome splash still the default host front door,\nfooter and polish nits like putting **Austin** on the copyright line). Under\nthe hood the site package was rebuilt and redeployed on Cloudflare so the live\ndomain stays the one product story—not a second abandoned stack.\n\nYou do not need to care which web framework we use. You need the site and the\napp to agree on the name.\n\n## How to get it\n\nSame install story, new app name in Applications:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nOr upgrade if you already have the cask:\n\n```sh\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nApp lands at **`/Applications/Astrohacker TermSurf.app`**. CLIs stay on PATH:\n**`ahterm`**, **`ahsh`**, **`ahweb`**, engine helpers, and **`ahcalc`** when\nthe package includes it.\n\nWorth five minutes after upgrade:\n\n1. Confirm the Dock tile is the **monogram** and the app name is **TermSurf**.\n2. `ahweb https://example.com` — type into the page without a second mode Enter.\n3. Split a 2×2 and walk the arrows; focus should not diagonal-jump.\n4. Run **`ahcalc`** once if you want the pane calculator.\n\nProtocol detail is still in\n[How TermSurf Talks](/blog/2026-07-19-how-termsurf-talks) and the\n[TermSurf protocol docs](/docs/termsurf). Product docs start at\n[/docs](/docs).\n\nUpgrade. Open a URL. Move focus on purpose. The window should feel like one\nproduct—with a name that matches the protocol that made it possible.\n",
            "url": "https://astrohacker.com/blog/2026-07-20-astrohacker-0-1-60",
            "title": "Astrohacker 0.1.60: TermSurf by Name, Browse by Default, Calc in a Pane",
            "summary": "Field notes from 0.1.47 through 0.1.60: Astrohacker TermSurf.app, monogram dock and surfer titles, ahweb Browse-first, ahcalc, smarter split focus, and the live site.",
            "date_modified": "2026-07-20T22:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-19-how-termsurf-talks",
            "content_html": "\nYou open a URL in a terminal pane and a **real** browser engine paints the page\nbeside your shell. No alt-tab. No second app fighting for focus. Chromium,\nWebKit, or Ladybird—same product window.\n\nThat is not one magical binary doing everything. It is several processes that\nhave to agree on layout, tabs, input, and page state. The agreement has a name:\n**TermSurf**.\n\n**Astrohacker Terminal** is the product you install. **TermSurf** is the\nprotocol those pieces use to talk. This post is the builder’s tour: what\nhappens when you run `ahweb`, who is on the wire, and why the messages look the\nway they do. For the full message catalog, see\n[TermSurf protocol docs](/docs/termsurf). This is the story, not a field dump\nof `termsurf.proto`.\n\n## What happens when you run `ahweb`\n\nPick a boring URL and a shipped engine:\n\n```bash\nahweb --browser chromium https://example.com\n```\n\nRoughly:\n\n1. **`ahweb` is a client.** It does not embed Chromium. It finds the Terminal\n   **host** and asks for browser work on a **pane** (the region you see).\n2. **`ahterm` is the host.** It owns the window, panes, and routing. It places\n   a browser **overlay** on that pane and talks to an **engine helper**.\n3. **`ah-chromiumd` (or webkit / ladybird) is the engine.** It owns a **tab**—a\n   real document instance—and a render surface the host can composite.\n4. The engine reports readiness, geometry context, URL, title, and load state.\n   The host draws the page into the pane. Chrome (URL bar, modes) stays in the\n   product UI, not in a random floating browser window.\n\nThe rule of thumb:\n\n- **Clients speak pane.**\n- **Engines speak tab.**\n- **The host binds the two.**\n\nIf you only remember one thing about TermSurf, remember that.\n\n## The cast\n\n| Role   | Shipped binary                               | Job                                                        |\n| ------ | -------------------------------------------- | ---------------------------------------------------------- |\n| Host   | `ahterm`                                     | Panes, compositing, TermSurf routing                       |\n| Client | `ahweb`                                      | Open URLs / drive browser panes from a tool                |\n| Engine | `ah-chromiumd`, `ah-webkitd`, `ah-ladybirdd` | Real browser process for a profile                         |\n| Shell  | `ahsh`                                       | Astrohacker Shell—the shell product, not the browser spine |\n\nEngine selectors for `ahweb` are family names: `chromium`, `webkit`,\n`ladybird`. **Gecko / `ah-geckod` is not released** yet; the protocol leaves\nroom for it. There is no meta `ah` dispatcher. Reserved for later:\n`ahwallet`.\n\nInstall story today: one Homebrew cask, Apple silicon, **Astrohacker\nTerminal**—see [Terminal docs](/docs/terminal) and [Web docs](/docs/web).\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nThat lands **Astrohacker Terminal.app** in `/Applications`, with PATH tools\nincluding `ahterm`, `ahweb`, `ahsh`, and the engine helpers.\n\n## Two pipes: sockets and protobuf\n\n### Unix domain sockets\n\nHost and client do not open a public TCP port for this. They use a **Unix\ndomain socket**: local IPC, a path on the machine, not “listen on the\ninternet.”\n\nThe client finds the host through the environment (notably\n`TERMSURF_SOCKET`). Same idea for other TermSurf-adjacent session variables\nlike pane id. Local, fast, private to your Mac.\n\n### Protocol Buffers\n\nThe wire language is **protobuf**, defined in `termsurf.proto`. Every frame is\na **`TermSurfMessage`**: an envelope whose payload is exactly one typed\nvariant—create a tab, move the mouse, report the URL, answer a query.\n\nWhy not free-form JSON per tool?\n\n- One schema for Zig/Rust/C++ sides of the stack.\n- Compact frames when input and page events get noisy.\n- A shared vocabulary so every new client does not invent its own dialect.\n\nYou do not need to love protobuf to use Terminal. You need to know it is the\n**contract** between host, clients, and engines.\n\n## Messages as jobs (not tag numbers)\n\nThink in **intents**, not field IDs.\n\n**Session.** Client says hello; host replies with what it can do. Host signals\nwhen a browser connection is ready for that work. Pane mode can flip between\nbrowsing and not.\n\n**Put a browser on a pane.** Client asks the host to place or update an\n**overlay** (geometry, URL, profile, engine hints). DevTools gets its own\noverlay path. Splits are “open another region,” still host-owned layout.\n\n**Tabs and surfaces.** Host tells the engine to create, resize, or close a tab.\nEngine answers with ready state and **surface / layer context** so the host can\ncomposite the page into the pane (on macOS, the path you care about is real\ncompositing—not a screenshot loop).\n\n**Input.** Keys, mouse, scroll, focus: host → engine, so the page receives what\nyou did in that pane.\n\n**Page events.** Engine → host: URL, title, loading, cursor, link targets,\nwhether back/forward/refresh make sense. That is how the chrome stays honest\nwhile the engine owns the document.\n\n**Navigation as a product.** Back, forward, and refresh are first-class\nactions—not only “set this URL string.” State messages tell the UI what is\navailable.\n\n**Queries and polish.** List tabs, ask for last URL or DevTools info,\nJS dialogs, HTTP auth, console lines, renderer crash signals. Some of that is\nproduct chrome; some of it is automation harness. Same protocol family.\n\nWe chose this set because a **multi-process, multi-engine browser in a\nterminal** needs exactly these seams. Not “RPC for everything.” Not a single\nWebView stuffed into every CLI.\n\n## Who talks to whom\n\n```text\n  ahweb  ──►  ahterm  ──►  ah-chromiumd / ah-webkitd / ah-ladybirdd\n    ▲            │                    │\n    └────────────┴──── events / replies ──┘\n```\n\n| Direction         | Why                                                                       |\n| ----------------- | ------------------------------------------------------------------------- |\n| **Client → host** | Ask for overlays, navigation, splits, queries without embedding an engine |\n| **Host → engine** | Create/resize/close tabs; inject input; drive load and navigation         |\n| **Engine → host** | Register, report surface and page state, surface dialogs/crashes          |\n| **Host → client** | Hello/ready, mode, query answers—enough state to run chrome or automation |\n\nDialog and auth replies close the loop when something outside the sandboxed\npage must answer a prompt. The host stays in the middle so the engine never has\nto know your pane layout, and the client never has to own a browser binary.\n\n## Why multi-process\n\nReal engines are large, crashable, and security-sensitive. Isolating them is not\noptional if you want Chromium-class behavior in a product window.\n\nMulti-process TermSurf also means:\n\n- **Many clients, one host.** `ahweb` today; other tools and apps later—same\n  language.\n- **No Chromium-in-every-CLI.** The install stays one Terminal plus helpers, not\n  a browser fork per command.\n- **Engine swap without rewriting clients.** Pick `chromium`, `webkit`, or\n  `ladybird`; the client still speaks pane-level intent.\n\nIn-process WebViews are simpler demos. They are a different product. We wanted\n**real engines** in panes. That forced a protocol.\n\n## What to do next\n\n1. Install on Apple silicon with Homebrew:\n\n   ```bash\n   brew tap astrohackerlabs/astrohacker\n   brew trust astrohackerlabs/astrohacker\n   brew install --cask astrohacker\n   ```\n\n2. Open **Astrohacker Terminal**, open a shell pane, and run\n   `ahweb https://example.com` (add `--browser webkit` or `ladybird` when you\n   want to feel the multi-engine claim).\n3. Read [TermSurf protocol](/docs/termsurf) if you implement a client or care\n   about the full message list.\n4. Read [Web](/docs/web) for the product tool surface and\n   [Terminal](/docs/terminal) for the host.\n\nThe point of TermSurf is boring on purpose: **one language** so a real browser\nand a real terminal can share a window without inventing a new wire format\nevery time we add a tool. When `ahweb` works, that language is doing its job.\n",
            "url": "https://astrohacker.com/blog/2026-07-19-how-termsurf-talks",
            "title": "How TermSurf Talks: The Protocol Behind Browser Panes in Astrohacker Terminal",
            "summary": "What happens when you run ahweb: host, client, and engine helpers speaking one protobuf language over local sockets—so a real browser can live in a terminal pane.",
            "date_modified": "2026-07-19T18:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-18-astrohacker-0-1-47",
            "content_html": "\nOn [July 17 we field-noted 0.1.29 through 0.1.37](/blog/2026-07-17-astrohacker-0-1-37):\nstock Terminal defaults (TokyoNight, borders, font, keybinds, ahsh, XDG), zsh\nunder ahsh for traditional mode, and quieter ahweb chrome.\n\nA day later the install line is still **one cask**, still **Apple silicon**,\nstill **The Agentic Hacker’s Terminal**. What changed is how the **window**\nreads when you split it—and what you see when the product opens its front door\non the web.\n\nThis post is the user-facing field notes from **0.1.37 through 0.1.47**.\n\n## The short version\n\n- **Multi-pane looks like a product** — every split pane gets **rounded borders\n  on all four corners**, not square strokes under a rounded window.\n- **Real air between panes** — `split-pane-gap` (default **4**) is empty margin,\n  not a thicker black paint bar. The 1 pt drag hairline matches **theme\n  background** when you leave `split-divider-color` alone.\n- **Load chrome fits the pane** — the surface progress bar stays inside the\n  rounded content box and picks colors from the **theme palette**.\n- **ahapp is out** — no TermSurf “app host” PoC in the Terminal package story.\n  Terminal + shell + web engines. Full stop.\n- **Fork tips moved** — Chromium, WebKit, Ladybird, Ghostty, and the shell stack\n  (including Nushell **0.114**) got release-gated updates through the line.\n- **Welcome to the Internet** — default host splash at\n  [astrohacker.com/welcome](https://astrohacker.com/welcome); the marketing\n  site went **dark-only** with GlyphRain and glass cards.\n- **Line** — **0.1.38 … 0.1.47** on the usual tap.\n\nIf you only remember one sentence: **upgrade, split a few panes, and the\nwindow should finally look like one UI—not a grid of sharp rectangles with a\nblack trench between them.**\n\n## Multi-pane that reads as cards\n\n0.1.37 already turned split borders **on** by default and stopped dimming\ninactive panes. That was necessary. It was not enough.\n\nOn modern macOS the window itself is rounded. Our borders were still drawn as\n**square strokes**. Outer corners clipped wrong. Internal T-junctions looked\nlike office cubicles, not panes in a serious host.\n\nWe fixed the geometry: **all four corners of every split pane** use a continuous\nradius—window-matched when `split-border-corner-radius = auto`, square when you\nset `0`, or a fixed point size when you set a number. Content and unfocused\noverlays clip **concentric** with the stroke so pixels do not square-fill past\nthe border band.\n\n### Gap is air, not paint\n\nWith borders on, the next failure mode was the **seam**. A one-pixel dark\ndivider is easy to ignore. Making it “thicker” by painting a wider\n`split-divider-color` rectangle is how you get a **black trench that sits on\ntop of the borders**—we tried that path, rejected it, and shipped the other\nmodel.\n\n**`split-pane-gap`** (default **4**, clamp `0`…`20`) reserves **empty layout\nspace** between pane frames. The painted divider stays a **1 pt** hairline for\ndrag. When `split-divider-color` is unset, that hairline uses the **theme\nbackground**—not a darkened near-black—so the seam blends and the full rounded\nborder stays visible.\n\nWant the old tight hairline-only layout? Set `split-pane-gap = 0`. Want a\nvisible accent seam? Set `split-divider-color` explicitly.\n\n### Progress bar in the pane\n\nOSC / load progress on a surface used to ignore the rounded clip and use\nsystem accent colors. It now lives in the **inset content box** with the same\ninner radius math as the terminal surface, and it reads palette indices that\ntrack the theme (cyan / red / yellow family with sane fallbacks).\n\nSmall thing. Multi-engine windows make it obvious when chrome is wrong.\n\n## Leaner package\n\nEarlier posts already cut the **editor** out of the cask. This line cut the\n**ahapp** TermSurf app-host PoC out of the product build and release story.\nYou still get:\n\n- **Astrohacker Terminal** (`ahterm`)\n- **ahsh**\n- **ahweb** and the engine helpers\n\nYou do not get a second half-product pretending to be part of the same install.\nIf it is not Terminal, Shell, or Web in this window, it is not in this cask.\n\nBuild scripts now treat **`ahterm`** as the primary component name (`aht` still\naliases for muscle memory). That is hygiene, not a feature—but naming is part\nof not lying to yourself about what you ship.\n\n## Fork tips as product quality\n\n0.1.38–0.1.47 is not only chrome. We ran release-gated updates on the engines\nand host:\n\n- **Chromium**, **WebKit**, **Ladybird** tips pinned and rebuilt for ship\n- **Ghostty** tip advanced on the product branch series\n- **Shell** stack moved with **Nushell 0.114** and exit-code fixes so `ahsh`\n  stays honest under the new port\n\nUsers do not install “a pin.” They install a cask that either builds engines\ncleanly or wastes a weekend. This line was a lot of the second kind of work so\nyou do not have to do it.\n\n## Welcome to the Internet\n\nThe Terminal’s default homepage is no longer a generic TermSurf welcome. It\nopens **[astrohacker.com/welcome](https://astrohacker.com/welcome)**: full-bleed\nsplash, dark only, **Welcome to / The Internet**, tagline **Advanced\nCommunications Network for Planet Earth**, slogan **Hack the Universe**, CTA\ninto docs.\n\nThe rest of the marketing site caught up: **dark-only** Tokyo Night, shared\n**GlyphRain**, glass cards so rain shows through, wider shell for heroes, prose\nmeasure for reading, unified **ASTROHACKER** wordmark. We fixed a stupid SPA\nbug where `/welcome` flashed **404** on refresh because the route was not\nprerendered and the hydrate shell was literally the 404 page. That should never\nhave shipped; it is gone.\n\nThis is not “we redesigned for brand guidelines.” It is: when an agent or a\nhuman lands in the product window, the first page should feel like the same\ncompany that put real browsers next to the shell.\n\n## How to get it\n\nStill one story:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nOr upgrade if you already have it. App lands in\n**Astrohacker Terminal.app**. Public CLIs: `ahterm`, `ahsh`, `ahweb` (plus\nengine helpers). **Apple silicon** only. No editor SKU. No second cask.\n\nLine covered here: **0.1.38 through 0.1.47**.\n\n## Closing\n\nWe spent this stretch making multi-pane feel intentional—rounded cards, real\ngaps, theme-native load chrome—and making the front door match the product\ninstead of a leftover PoC domain. The engines and shell underneath moved too,\nbecause a pretty border on a stale fork is still a stale fork.\n\nSplit a window. Open a couple of engines. If it still looks like duct tape, tell\nus. If it finally looks like one terminal that happens to run the web, that was\nthe point.\n",
            "url": "https://astrohacker.com/blog/2026-07-18-astrohacker-0-1-47",
            "title": "Astrohacker 0.1.47: Rounded Panes, Real Gaps, Welcome to the Internet",
            "summary": "Field notes from 0.1.37 through 0.1.47: card-like multi-pane chrome, engine tip upgrades, ahapp out of the package, and a cypherpunk welcome splash.",
            "date_modified": "2026-07-18T22:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-17-astrohacker-0-1-37",
            "content_html": "\nOn [July 17 we field-noted 0.1.17 through 0.1.29](/blog/2026-07-17-since-astrohacker-0-1-17):\nreal browser toolbar, shell less leaky, install path less aspirational, and the\n**editor cut out of the cask**.\n\nA few releases later the install line is still **one cask**, still **Apple\nsilicon**, still **The Agentic Hacker’s Terminal**. What changed is the **blank\ncanvas**. Stock Astrohacker Terminal used to open like a fresh Ghostty with\nproduct engines bolted on. Now it opens more like a setup someone already\nlived in for a week—on purpose.\n\nThis post is the user-facing field notes from **0.1.29 through 0.1.37**.\n\n## The short version\n\n- **Stock Terminal has opinions** — TokyoNight, visible theme-relative split\n  borders, no dimming of inactive panes, JetBrainsMono Nerd Font at 12pt, and a\n  split/tab keybind map baked in.\n- **Default shell is ahsh** — not via “hope Dock has Homebrew on PATH,” but via\n  absolute paths (`/opt/homebrew/bin/ahsh`, then `/usr/local/bin/ahsh`), with\n  the normal system shell if neither is there.\n- **Session config home** — when unset, we inject `XDG_CONFIG_HOME=$HOME/.config`\n  so children (including the shell) share a sane layout on macOS.\n- **Traditional mode is zsh** — bootstrap and alt mode load the shell macOS\n  users actually configure; **nu stays the default** interactive mode;\n  **Shift+Tab** is called out on the banner.\n- **Ahweb chrome** — rounded boxes stay rounded when disabled; disabled is a\n  **color** change, not a geometry flip.\n- **Line** — **0.1.30 … 0.1.37** on the usual tap.\n\nIf you only remember one sentence: **upgrade, open from the Dock once, and a\nstock install should look and behave less like an empty config file.**\n\n## Stock Terminal defaults\n\nThis window was mostly me taking the personal config I actually run and asking:\nwhat should every new user get without pasting a gist?\n\n### Theme: TokyoNight\n\nGhostty’s upstream default is “no named theme”—hard-coded colors that are fine\nand forgettable. We default the product theme to **TokyoNight** (exact resource\nname, capital T and N). Light and dark both point at that face unless you set\n`theme` yourself.\n\n### Splits that read as UI\n\nInactive panes used to **fade**. Borders used to be off unless you opted in.\nThat combination is how multi-pane terminals become a guessing game.\n\nStock defaults now:\n\n- **Split border width 2**\n- Unset focused / unfocused border colors fall back to theme **palette[6]** /\n  **palette[8]** (cyan / bright black on TokyoNight)\n- **Unfocused opacity 1** — no dim overlay; **borders** mark focus\n\nIf you liked the fade, set `unfocused-split-opacity` below 1. Explicit border\ncolors and `split-border-width = 0` still work.\n\n### Type and chords\n\n- **Font:** JetBrainsMono Nerd Font at **12pt** (you still need the face\n  installed on the machine).\n- **Keybinds** (macOS; `cmd` = Super), including:\n\n  - `cmd+h/j/k/l` — new split left / down / up / right\n  - `ctrl+h/j/k/l` — focus split\n  - `ctrl+alt+arrows` — resize\n  - `ctrl+shift+h/l` and arrows — tabs\n  - `ctrl+shift+z` — zoom split\n\nLast-wins on shared triggers: product defaults replace some upstream defaults\n(for example `cmd+k` is no longer clear-screen). **`cmd+h`** can still lose to\nmacOS Hide—that is the OS, not a promise we can fully keep.\n\nThis is not a settings panel. It is **baked defaults**. Your config still wins\nwhen you set the keys.\n\n### Shell process: ahsh even from the Dock\n\nHomebrew puts `ahsh` on PATH for **shells you launch from a configured\nenvironment**. A **`.app` launched from the Dock** does not magically inherit\nthat PATH.\n\nSo we do not default to bare `command = ahsh` and pray. At finalize we try, in\norder:\n\n1. `/opt/homebrew/bin/ahsh`\n2. `/usr/local/bin/ahsh`\n\nFirst path that exists becomes the default command. If neither exists, we fall\nthrough to Ghostty’s normal system shell story (`SHELL` in CLI contexts, passwd\nshell, then a last-resort `sh`).\n\nWe also inject **`XDG_CONFIG_HOME=$HOME/.config`** when neither the process env\nnor your config already set it—so session children share XDG layout without\nhardcoding a username. Pre-set env and explicit `env =` still win.\n\n## Shell: zsh where macOS actually lives\n\n`ahsh` still defaults to **nu** for interactive work. What changed under the\nhood is the **traditional** path and the **bootstrap** path.\n\nmacOS users put PATH, brew, nvm, and friends in **zsh** files—not in a museum\n`bash` 3.2 login. We switched the external worker from bash to **zsh**: login\nplus an explicit path that still picks up **`.zshrc`-class** setup so a first\ndownload is not a blank PATH.\n\nMode cycle is **nu ↔ zsh**. The startup banner hints **Shift+Tab**. Docs live\nunder [Shell](/docs/shell).\n\nIf your muscle memory was “I need my zsh env before nu feels useful,” that is\ncloser to automatic now.\n\n## Ahweb chrome: one geometry\n\nBrowser-in-pane chrome had a small lie: disabled nav buttons could look like a\n**different shape** of box than enabled ones. Stock TUI now keeps **rounded**\nframes for the chrome that matters (nav, URL, viewport). Disabled is **color**,\nnot a square-vs-rounded flip. Mode focus still reads through border color, not\nborder type.\n\nSame product surface—less “three widgets from three demos.”\n\n## Install line (still boring on purpose)\n\nStill one Homebrew cask, still Apple silicon, still ad-hoc codesign and\n`brew trust` as **tap** trust—not Apple notarization. Engines are still heavy\non first launch because they are real.\n\nThis window also included WebKit packaging work (sandbox exclusion archive) so\n“release builds WebKit” stays a sentence we can finish. That is reliability,\nnot a new engine brand.\n\nCurrent line at time of writing: **0.1.37**.\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n# or\nbrew update && brew upgrade --cask astrohacker\n```\n\nSmoke:\n\n```bash\nahterm +version\nahsh --version\nahweb --version\n```\n\nOpen the app **from the Dock once** after upgrade. That is the PATH story you\nare actually testing—not only a shell where Homebrew is already on `PATH`.\n\n## What we did not ship\n\nSame honesty bar as 0.1.17 / 0.1.29:\n\n- **Gecko** is not a product engine on the cask.\n- **Wallet**, mobile, web Economy, English shell product, AI marketplace,\n  first-party hosted models — direction or later, not “install and use today.”\n- **Notarized / Developer ID** shipping is still ahead.\n- We did **not** promise your old personal keybinds are unchanged. Some\n  product defaults intentionally override upstream Ghostty chords.\n\nInternal monorepo workspace reorg and agent breadcrumbs shipped in this\nwindow. They make the tree easier to build; they are not a user feature.\n\n## Who this is for\n\nUnchanged: agentic builders on **Apple silicon** who live in a terminal and\nhate Cmd-Tab tax for “open the docs / dashboard / OAuth page.”\n\nIf you installed for **browsers in panes**, upgrade—defaults and shell\nbootstrap are less of a DIY kit.\n\nIf you rely on **upstream Ghostty’s stock chords and empty theme**, read the\ndefaults section: the product is more opinionated now. Override what you\ndislike; that is still a config file, not a trap.\n\n## What to do\n\n```bash\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nCold-launch from the Dock. Confirm TokyoNight, split borders, **ahsh**, and\nthat tools from your zsh config show up in nu after bootstrap.\n\nIf JetBrainsMono Nerd Font is missing, install the face or set `font-family`.\nIf ahsh is missing from the cask PATH layout, that is a bug report—the absolute\npath search should still hit the Homebrew bin we ship.\n\nRead the [docs](/docs). Remove personal config lines that only duplicated\nthese defaults if you want a thinner file.\n\nWe will keep shipping the same way: **focus the Terminal wedge, bake what\nworks, prove it on a real install, cut the rest.**\n",
            "url": "https://astrohacker.com/blog/2026-07-17-astrohacker-0-1-37",
            "title": "Astrohacker 0.1.37: Opinionated Defaults, Zsh Under the Hood",
            "summary": "Field notes from 0.1.29 through 0.1.37: stock Terminal defaults (theme, borders, font, keybinds, ahsh, XDG), zsh under ahsh, and cleaner ahweb chrome.",
            "date_modified": "2026-07-17T22:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-17-since-astrohacker-0-1-17",
            "content_html": "\nOn [July 13 we announced 0.1.17](/blog/2026-07-13-astrohacker-0-1-17): real\nbrowser engines in panes next to your shell on Apple silicon, one Homebrew\ncask, early-adopter honesty.\n\nA few days later the install line is still **one cask**, still **Apple silicon**,\nstill **The Agentic Hacker’s Terminal**. The workbench is not the same. This\npost is the field notes from **0.1.17 through 0.1.29**—what got better, what we\nripped out, and what you should expect when you upgrade.\n\n## The short version\n\n- **Browser panes grew a real toolbar** — Back, Forward, Refresh that work in\n  the product window, not as science experiments.\n- **Shell got less leaky** — startup and alt-mode behavior that was eating\n  sessions got fixed and re-qualified on real installs.\n- **Install quality stopped being aspirational** — legal package, WebKit\n  packaging and quarantine fixes, coherent public releases instead of “hope\n  the archive matches the story.”\n- **The editor is gone** — no Helix-based Terminal editor, no `ahed` on PATH,\n  no “editor is included” marketing. Terminal + shell + web engines. Full stop.\n\nIf you only remember one sentence: **we doubled down on the multi-engine\nterminal and stopped shipping a second product inside the same install.**\n\n## Why cut the editor\n\n0.1.17 listed four surfaces in the install story: Terminal, Shell, Editor, Web.\nThat was honest about how the tree was built. It was a bad focus tax.\n\nA Helix fork is a product: runtime, grammars, themes, packaging, health checks,\ndocs, release gates. Maintaining that _and_ three real browser engines _and_ a\nhost terminal is how you spend a month polishing the wrong wedge.\n\nAstrohacker’s bet is the **agentic workbench**: shell and agents in one window\nwith **real browsers** (Chromium, WebKit, Ladybird) and real profiles—not “also\na modal editor because the monorepo had one.”\n\nSo we deleted it. Fork, patches, packaging, cask install, current docs and\nmarketing. Recovery is git history if we ever need the corpse. History posts\nthat mention the editor stay as history. New installs do not get an editor\nbinary.\n\n**Not a rename.** Not “coming back next week under a cooler name.” Removal.\nFuture editors, if any, get their own product design—not a silent revive of\nthe old PATH name.\n\n## Browser panes that behave like a browser\n\nThe 0.1.17 post sold engines in panes. Users still needed **chrome that\nrespects history**.\n\nSince then we shipped and product-qualified:\n\n- **Back** — per engine, through the host chrome, not a pretend button.\n- **Forward** — same contract the other direction.\n- **Refresh** — including idle icon layout that does not look half-drawn.\n\nUnder the glass we also pushed **shared native input** (text, pointer paths,\nediting responder work) so panes feel less like three unrelated demos glued\ninto one window.\n\nAnd a nasty layout bug: **split views that swallowed the web surface**. If you\nsplit a pane and the page vanished into the void, that was real. It is fixed\nand checked across engines. Your split bindings are supposed to stay yours.\n\n## Shell: stop the session tax\n\nRight after 0.1.17 we hit a **shell startup / capture** problem that could\nwreck a session before you noticed. That landed as a verified hotfix path\n(**0.1.19** era) and follow-on work: safer startup, configured alt-mode\nswitching that does not lie about which shell you meant.\n\nIf your muscle memory is “open Terminal, live in `ahsh`,” that path is more\nboring now. Boring is the goal.\n\n## Install and release: make “Homebrew” mean something\n\nEarly post-0.1.17 life included the unglamorous work:\n\n- **CLI identity** — what ships on PATH is the Terminal set (`ahterm`, `ahsh`,\n  `ahweb`, `ahapp`, engine helpers). No editor. No meta-`ah` dispatcher.\n- **Legal package** in the release tree (LICENSE, NOTICE, trademarks, third-party\n  artifacts) so the archive is not a bag of binaries with a shrug.\n- **WebKit packaging** — staged links, signature expectations, quarantine /\n  xattr cleanup so “installed cask” and “works after first launch” are closer\n  to the same sentence.\n- **Release restoration** after regressions—engines and public installs repaired\n  through a sequence of public versions (**0.1.20–0.1.23**), not abandoned.\n- **One-command Homebrew release** orchestration so the next patch is not a\n  ritual of forgotten steps.\n- **Preserve build caches** on routine release so WebKit/Chromium/Ladybird do\n  not full-rebuild because someone confused “release mode” with “delete the\n  universe.”\n- **First-party crate versions** track the cask version on release. Forks stay\n  out of that bump.\n\nCurrent line at time of writing: **0.1.29** via the usual tap.\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n# or\nbrew update && brew upgrade --cask astrohacker\n```\n\nSmoke after upgrade:\n\n```bash\nahterm +version\nahsh --version\nahweb --version\n```\n\nYou should **not** expect `ahed` anymore. If an old install left editor config\nunder `~/.config/astrohacker/editor`, uninstall zap may still clean it; the\nproduct does not reinstall it.\n\n**Still true from 0.1.17:** ad-hoc codesign, `brew trust` is tap trust not Apple\nnotarization, first launch can be heavy because engines are real.\n\n## Website and slogan (quick)\n\n- Slogan is **The Agentic Hacker’s Terminal** again—we briefly tried a shorter\n  form and put the agentic word back where it belongs.\n- Public docs got a craft pass (Terminal-first, less packaging lecture).\n- About page carries the manifesto energy; install cards say **Astrohacker\n  Terminal**, not “bundle of SKUs.”\n- Brand monogram work landed for assets that need a sharp mark.\n\nProcess side, if you care how the sausage ships: we kept running **Issues and\nExperiments** hard on this window—navigation, splits, release, editor removal\nall went through design/result gates. That is [how we get agents solving\ndefined work overnight](/blog/2026-07-15-how-to-get-ai-solving-problems-for-you-while-you-sleep),\nnot a claim that the product is finished.\n\n## What still is not shipped\n\nSame honesty bar as 0.1.17:\n\n- **Gecko** embedding is research, not a product engine on the cask.\n- **Wallet**, mobile, web app, English shell product, AI marketplace, Economy\n  flows — direction or later work, not “install and use today.”\n- **Notarized / Developer ID** shipping is still ahead.\n\nWe did a lot of Gecko _parity experiment_ work in this window. That is\nengineering progress, not a download button.\n\n## Who this is for\n\nUnchanged audience: agentic builders on **Apple silicon** who already live in\nthe terminal and hate Cmd-Tab tax for “open the docs / dashboard / OAuth page.”\n\nIf you installed 0.1.17 for **browsers in panes**, upgrade. The toolbar and\ninstall path are less of a science fair.\n\nIf you installed 0.1.17 primarily for the **included modal editor**, this line\nwill disappoint you on purpose. Use the editor you already trust; we are not\ncompeting there right now.\n\n## What to do\n\n```bash\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nRead the [docs](/docs). Open a pane. Hit Back when you mean Back.\n\nIf something still vanishes when you split, or an engine fails after upgrade,\nthat is a bug report—not a lifestyle choice. We will keep shipping patches\nwith the same rule we used on the editor: **focus the Terminal wedge, prove\nit, cut the rest.**\n",
            "url": "https://astrohacker.com/blog/2026-07-17-since-astrohacker-0-1-17",
            "title": "Astrohacker 0.1.29: Terminal Focus, Real Toolbar, Editor Gone",
            "summary": "What shipped from 0.1.17 through 0.1.29—browser Back/Forward/Refresh, shell hardening, install repairs, and why the Terminal no longer includes an editor.",
            "date_modified": "2026-07-17T20:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-15-how-to-get-ai-solving-problems-for-you-while-you-sleep",
            "content_html": "\nYou write down what “solved” means. You walk away. In the morning the issue has\na plan commit, a result commit, tests that ran, and a second agent that tried to\nkill the work before it landed.\n\nThat is the product of a habit, not a vibe session.\n\nWe run that habit at Astrohacker as **Issues and Experiments** (InE). It is how\nwe ship small brand fixes in an afternoon and how we keep multi-day engine and\nrelease work coherent when no human is mid-loop. This is not a pitch for a new\ncoding model. It is a way to get the agents you already use—Codex, Claude Code,\nGrok, Cursor, and friends—to keep solving **defined** problems without you\nbabysitting the chat.\n\nIf you want the original lifecycle manifesto, read [Building Software While You\nSleep](/blog/2026-06-01-building-software-while-you-sleep). This post is the\nfield guide: same loop, different diameters, any harness, and a workbench that\nmatches the idea.\n\n## The only job that is still yours\n\nYou do not “prompt harder.” You **specify**.\n\nAn issue that can run overnight needs three things written down before anyone\ntypes code:\n\n1. **Goal** — one coherent outcome, not a wish list.\n2. **Verification** — commands and observations that would convince a skeptic\n   the goal is met.\n3. **Guardrails** — what is out of scope, what must stay honest, what must not\n   be rewritten.\n\nOnce that exists, solving becomes mechanical enough that an agent can own the\nmiddle of the loop. You are not the implementer. You are the person who made\n“done” falsifiable.\n\n## Issues and Experiments, one screen\n\n**Issue** — a folder with a README: goal, verification, constraints, status.\nDurable. In git. Not a Discord message.\n\n**Experiment** — one decision-complete step toward the goal. Design it. Get it\nreviewed. Commit the plan. Implement only then. Verify. Record Pass / Partial /\nFail. Get the result reviewed. Commit the result. **Then** design the next one.\n\nYou never list experiment 1 through 12 up front. Experiment N’s result is what\ntells you what N+1 should be. Failure is not drama. It is information.\n\n**Adversarial review** — a second agent, cold context, preferably a different\nharness when you can. Design review before implementation. Completion review\nbefore the result commit. Marking your own homework is how slop ships overnight.\n\nInE is **not** a coding tool. It does not replace Codex, Claude Code, Grok, or\nCursor. It is the honesty and progress layer those tools plug into. The agents\nwrite the code and run the tests. The issue file owns the truth.\n\n## Same loop, different diameter\n\nThe machine does not change when the problem shrinks or grows. Only the diameter\ndoes.\n\n**Hours.** Restore a slogan, fix a CLI identity leak, close a one-surface copy\nmistake. One experiment. Still: design review, plan commit, implement,\n`test:whatever` that actually gates the claim, completion review, result commit.\nSmall work with real positioning risk does not get a free pass because it is\n“just marketing.”\n\n**Days.** Multi-engine parity, release restoration, long host work. The issue\nstays open. Experiments stack. Sessions end and restart. What survives the night\nis not a 40-turn chat transcript—it is the issue README, the experiment files,\nand the commits that mark plan vs result. Morning context is `git log` and a\nmarkdown notebook, not “remind the model what we were doing.”\n\nThat is why sleep works. Resume is reading the record, not re-explaining the\nuniverse.\n\n## Two receipts\n\n### Multi-day: work that refuses to fit in one sitting\n\nWe have used InE on terminal and engine work that spans multiple days: open\nissue, clear “done,” experiments that cannot all be designed on day one because\nday one’s failures rewrite day two. Orthogonal review keeps implementers from\ndrifting when the human is offline. The proof is in the `issues/` tree and the\ncommit history—not in a slide about “AI productivity.”\n\nWhat would break without the loop: scope expands every time an agent hits a\nwall; “almost works” gets declared done; the chat that held the plan dies with\nthe session.\n\n### Small: still specify, still review\n\nWe have also used the same shape on problems that take a single afternoon—brand\nand site copy, install surface honesty, slogan and title lines that must match\nwhat we actually market. One decision-complete experiment. Same dual review.\nSame two commits.\n\nWhat would break without the loop: a “quick” agent edit that leaves canon,\nhomepage, and CI disagreeing—or a short slogan that sounded fine until you\nremembered why the long form existed.\n\nTiny diameter. Same machine.\n\n## Use any coding harness\n\nInE does not care who wrote the patch.\n\n- **Implementer** — Codex, Claude Code, Grok, Cursor, whatever is sharp today.\n- **Reviewer** — a cold second look; a different harness when you can (orthogonal\n  review). Fresh context matters more than brand loyalty.\n- **System of record** — the issue and experiment files in the repo.\n\nSwap models next month. The issue still closes the same way: verification\npasses, reviews pass, commits exist, status flips to closed.\n\nIf your process only works inside one vendor’s chat product, you do not have a\nprocess. You have a subscription.\n\n## Anti-patterns (steal these as rules)\n\n- Designing a long experiment list before the first result exists.\n- Skipping design review “because it’s small.”\n- Treating chat as the system of record.\n- Combining plan and result into one commit.\n- Expanding scope when an experiment fails instead of writing what you learned.\n- Declaring victory without the verification commands you wrote when you were\n  sober.\n\n## When not to bother\n\nDo not open an issue for a typo with no risk.\n\nDo not automate pure exploration until you can say what “done” means. First write\nthe goal. Then open the issue. Then sleep—or don’t, but at least the machine\nknows the target.\n\n## The workbench we run it in\n\nIf the loop is harness-agnostic, the host should not lock you to one chat\nwindow and a separate browser.\n\n**Astrohacker Terminal** is the native app we use for that work: a serious\nterminal host with **multiple real browser engines** and **multiple profiles**\nin the same window, plus the shell, editor, and web tools that ship in the same\ninstall. Run the coding agents you already use—Codex, Grok, Claude Code, Cursor,\nand friends—next to real web panes, not in a pile of unrelated apps.\n\nInE is still the method. The Terminal is the place the method lives when agents\nneed a shell and a browser at the same time.\n\nApple silicon, Homebrew:\n\n```sh\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nSteal the process even if you never install us. Install us if you want the\nworkbench built for the same idea.\n\nSet the goal. Let the agents iterate. Wake up to receipts.\n",
            "url": "https://astrohacker.com/blog/2026-07-15-how-to-get-ai-solving-problems-for-you-while-you-sleep",
            "title": "How to Get AI Solving Problems For You While You Sleep",
            "summary": "Issues and Experiments: a harness-agnostic loop so agents keep solving real work overnight—and across days—whether the implementer is Codex, Grok, Claude Code, or Cursor.",
            "date_modified": "2026-07-15T18:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-14-why-ghostty-is-the-greatest-terminal",
            "content_html": "\nYou live in a terminal now more than you did five years ago.\n\nNot because nostalgia won. Because agents run there. Shells run there. Editors,\ntest runners, `git`, and half the control plane of modern software run there.\nThe window you keep open for twelve hours is not a browser with a dock icon. It\nis a grid of panes that refuse to become chrome.\n\nSo the terminal has to be great again. Not “pretty.” Not “configurable until it\nbecomes a second operating system.” **Great**—native, fast, correct, and boring\nin the ways that let you forget it exists.\n\n**Ghostty is the greatest terminal** under that definition.\n\n## What “greatest” means here\n\nI am not ranking every escape sequence ever implemented. I am not scoring Sixel\ntrivia or remote-mux Olympics.\n\nFor people who live in the shell—including people who run coding agents all\nday—great means:\n\n1. **Native where you are.** On macOS, it should feel like a macOS app. On\n   Linux, like a real desktop citizen—not a cross-platform skin.\n2. **Fast by default.** You should not notice the terminal under scroll, resize,\n   or a noisy build.\n3. **Modern terminal correctness.** True color, solid Unicode, shell\n   integration, the stuff you only notice when it is broken.\n4. **A real product.** Windows, tabs, splits, menus, settings—not a research\n   renderer duct-taped to a PTY.\n5. **Architecture that can last.** Core that is engineered, not a ball of glue.\n\nGhostty wins those. That is the claim.\n\n## Native is not a theme\n\nMost terminals ship one UI story and paint it on every OS. Ghostty does the\nharder thing: **platform-native UI** with a shared core.\n\nOn macOS, Ghostty is a real Swift app—windowing, menus, settings, the\nintegration surface you expect from software that belongs on the machine. The\nrenderer talks **Metal**. Font discovery uses **Core Text**. That is not a\nmarketing bullet; it is the shortest path from “glyph” to “pixels on an Apple\nSilicon laptop.”\n\nOn Linux, the GUI is its own first-class shell (GTK), with OpenGL acceleration.\nSame product idea: native shell, shared engine.\n\nThe engine is **libghostty**—a Zig core exposed as a C-ABI library: terminal\nemulation, fonts, rendering. The apps are consumers of that core. That split is\nwhy Ghostty can feel native without forking the entire terminal state machine\nper platform.\n\nIf you have ever used a terminal that _almost_ looks right on a Mac—menus that\nfeel foreign, fonts that feel slightly wrong, GPU path that is “Metal via three\ntranslation layers”—you know why this matters. Ghostty is not almost.\n\n## Speed is the absence of a feeling\n\nThe best terminal performance is invisible. You resize a split and the grid\nkeeps up. You flood the PTY with compiler output and the UI does not become a\nslide show. You type, and the shell is the bottleneck—not the emulator.\n\nGhostty is built as a **GPU-accelerated** terminal from the ground up. Metal on\nmacOS. OpenGL on Linux. A heavily optimized parse path for the firehose of\nbytes that real work produces. Dedicated rendering architecture instead of\n“paint when we get around to it.”\n\nYou can always find a microbenchmark war online. Lived experience is simpler:\nwhen the terminal disappears under load, you keep working. Ghostty is in that\nclass. That is table stakes for anyone who runs agents, watchers, and logs in\nthe same window for hours.\n\n## A terminal, not a platform\n\nSome emulators win by becoming everything: remote multiplexer, scripting host,\nplugin economy, second desktop environment. Power exists there. So does\ncomplexity tax.\n\nGhostty’s bet is different. It is a **terminal product**—tabs, splits,\nkeybindings, configuration, shell integration, modern protocols—without making\n“embed a whole programming language in your config” the center of the story.\nConfiguration is first-class. The daily surface stays a terminal.\n\nThat restraint is a feature. When your day is already full of agents, editors,\nand half-finished plans, the host should not demand a second career.\n\n## Serious engineering\n\nGhostty is not a weekend wrapper around someone else’s VT parser with a glow\ntheme.\n\nIt is a full-stack terminal project: custom event-loop DNA, a real font stack,\nplatform renderers, a C-API boundary between core and GUI, and a public product\nthat people actually daily-drive. **libghostty** is the long game—an embeddable\nmodern terminal core so the hard work of emulation and rendering is not\nre-solved by every app that needs a grid of cells.\n\nYou feel that seriousness in the details. Selection behaves. Scrollback holds\nup. The app shell does not fight the OS. Upstream is active. The project treats\nthe terminal as infrastructure, not as a skin.\n\nGreat tools usually look like that: boring competence stacked high enough that\nit becomes charisma.\n\n## What Ghostty is not\n\nGhostty is not the winner of every checkbox on every platform on every day.\n\nIt is not a Windows-first product today—macOS and Linux are the shipping\nstory; Windows is a longer path. It is not trying to replace tmux-over-SSH as a\nlifestyle. It will not match every graphics protocol or config dialect of every\nlegacy emulator.\n\nIf your primary requirement is “one binary, every OS, every protocol, Lua all\nthe way down,” you may pick something else and be happy.\n\nIf your requirement is **the best place to live in a shell on a modern Mac (or\nLinux box)**—fast, native, correct, product-grade—Ghostty is the bar.\n\n## Why this matters more now\n\nCoding agents made the terminal the control plane again.\n\nClaude Code, Codex, Grok, OpenCode, Pi—whatever you actually run—the loop is\npane-shaped. Repo in one split. Agent in another. Logs in a third. You need a\nhost that does not flake under that density. You need something that feels like\npart of the computer, not a guest UI.\n\nGhostty is the greatest terminal for that life because it gets out of the way\nwithout going dumb. Native craft. GPU path. Real app. Serious core. That is the\nfoundation you want under agent chaos.\n\n## What we built on top\n\nWe did not want to rebuild a great terminal from scratch.\n\nAstrohacker Terminal is built on Ghostty’s model as the host: the same bet on\nnative panes, speed, and a real macOS app shell. What we add is the thing Ghostty\nis not trying to be—**real browser engines in the same window as the shell**.\nChromium, WebKit, Ladybird; multiple profiles; a page next to the agent that is\nstill working.\n\nIf you only need the greatest terminal, use [Ghostty](https://ghostty.org/).\n\nIf you want that foundation with browsers in the panes, install Astrohacker:\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nDocs live at [astrohacker.com/docs](https://astrohacker.com/docs).\n\nThe order is intentional. Ghostty first. Host second. The terminal had to be\ngreat before anything else belonged in the window.\n",
            "url": "https://astrohacker.com/blog/2026-07-14-why-ghostty-is-the-greatest-terminal",
            "title": "Why Ghostty Is the Greatest Terminal",
            "summary": "Ghostty is what a modern terminal should feel like—native, fast, and serious. Here’s why, and what we built on top of it.",
            "date_modified": "2026-07-14T16:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-13-astrohacker-0-1-17",
            "content_html": "\nYou are mid-session on a MacBook Pro. Codex or Claude Code or Grok is grinding\nthrough a change in one pane. Another pane has the repo. A third has whatever\nyou were editing before the agent rewrote it.\n\nAnd the docs? The OAuth screen? The CI log that only renders as a web UI? Those\nare still in a separate browser, three spaces over, cookies mixed with your\npersonal Gmail.\n\n**Astrohacker 0.1.17 puts real browser engines in panes next to that work.**\n\nSame window. Same flow. Chromium, WebKit, and Ladybird—each with isolated\nprofiles—beside the shell and editor you already live in.\n\nThis post is for early adopters who already treat the terminal as home base:\nagentic builders on Apple silicon who run coding agents all day and are willing\nto try something rough if it kills the Cmd-Tab tax.\n\n## What 0.1.17 is\n\nAstrohacker ships as **one desktop install**, not four consumer products.\n\nYou get:\n\n- **Terminal** — the host app. Ghostty-based. Panes, tabs, and configuration\n  you expect from a serious terminal, plus browser panes in the same window.\n- **Shell** — included. Structured, Nushell-lineage tooling in a single binary.\n- **Editor** — included. Modal Helix-style editing with language tooling\n  in-process.\n- **Web** — open a real engine in a pane from a shell command.\n- **Engine helpers** — Chromium, WebKit, Ladybird. You do not day-drive these;\n  the product does.\n\nPlatform for this release: **Apple silicon macOS**. If you are not on that,\nthis post is not your install path yet.\n\nWhat is **not** in 0.1.17 as a shipped product surface:\n\n- Gecko / Firefox embedding (`ah-geckod` is research, not released)\n- Wallet\n- Mobile, web app, marketplace, or “Economy” start flows\n\n0.1.17 is early. It is usable. It is not pretending to be polished forever\nsoftware.\n\n## Why agentic builders care\n\nCoding agents already made the terminal the control plane. The missing piece\nwas the **web surface that still owns half of software work**.\n\nWith Astrohacker you can:\n\n- Keep the **agent CLI**, the **repo**, and the **page you are verifying** in\n  one window\n- Use a **work profile** for GitHub / cloud consoles and a **personal profile**\n  for everything else—without a second browser user ceremony\n- Open the **same URL in Chromium, WebKit, or Ladybird** when something smells\n  engine-specific\n- Stay in flow when the agent says “check the docs” or “log into the dashboard”\n\nAgents draft and edit. You still have to _see_ the web. That loop should not\nrequire leaving the terminal.\n\n## Install with Homebrew\n\nApple silicon MacBook Pro. Homebrew. One cask.\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nUpgrade later:\n\n```bash\nbrew update\nbrew upgrade --cask astrohacker\n```\n\nSmoke checks after install:\n\n```bash\nahterm +version\nahsh --version\nahed --version\nahed --health rust\n```\n\nYou should see **0.1.17** (or the version the cask currently points at after an\nupgrade). `ahed --health rust` should work without manually setting\n`ASTROHACKER_EDITOR_RUNTIME`.\n\n**What the install includes on PATH:** `ahterm`, `ahsh`, `ahed`, `ahweb`,\n`ahapp`, plus engine helpers `ah-chromiumd`, `ah-webkitd`, and `ah-ladybirdd`.\nThere is no meta `ah` dispatcher. Reserved for later: `ahwallet`.\n\n**Signing note (read this once):** install uses ad-hoc codesign and clears\nquarantine. `brew trust` trusts the **tap**, not Apple notarization. Full\nDeveloper ID / notarized shipping is still ahead. That is honest early-adopter\nsoftware, not a silent security claim.\n\nFirst run can feel heavy. Engines are real engines. Warmup and disk use are\npart of the deal.\n\n## The workbench\n\nCapability first. Identifiers second.\n\n### Terminal (`ahterm`)\n\nOpen **Astrohacker Terminal**. That is the app. `ahterm` is the launcher on\nPATH.\n\nThis is the host: multi-pane terminal work, plus browser panes that resize with\nthe layout. Native terminal features come from the Ghostty lineage. Astrohacker\nadds the TermSurf protocol path, multi-engine profile servers, and the chrome\nthat keeps browser and shell panes readable together.\n\n### Shell (`ahsh`)\n\n`ahsh` is Astrohacker Shell—Shannon / Nushell family, packaged with Terminal.\nTooling lives in the binary instead of starting life as a plugin zoo.\n\nIt is structured when you want structured pipelines. It also has a **zsh alt\nmode** when you need a familiar traditional subprocess without abandoning the\nshell you launched (macOS-default env via zsh, not bash).\n\nConfig follows Nushell habits (`env.nu`, `config.nu` under your Nushell config\ndir).\n\n### Editor (`ahed`)\n\n`ahed` is a Helix-based modal editor. Vim-ish keys. Language tooling and\nsyntax in-process. It ships with runtime assets so a normal Homebrew install\ndoes not require you to invent environment variables first.\n\nUseful checks: `ahed --version`, `ahed --health rust`.\n\n### Web (`ahweb`)\n\nThis is the command you will actually type.\n\nFrom a pane inside Astrohacker Terminal:\n\n```bash\nahweb example.com\nahweb example.com --browser webkit\nahweb example.com --browser ladybird --profile work\n```\n\n`ahweb` draws the terminal chrome (URL bar, modes, status). The page itself is\na real engine surface composited into the pane—not a toy HTML renderer.\n\nModes are intentionally modal: Control for terminal keybindings, Browse for\nkeyboard/mouse into the page, Edit for the URL, Command for `:` commands.\nThat is the same muscle memory most of us already have from editors and\nbrowsers that respect focus.\n\nEngine selectors are family names: `chromium`, `webkit`, `ladybird`. Future\n`gecko` is not a product claim yet.\n\n### Apps (`ahapp`)\n\n`ahapp` launches GTUI in-terminal apps when the Terminal pane environment is\npresent. Same product install. Smaller surface area than `ahweb` for most\npeople day one—know it exists when you need an app, not just a URL.\n\n### Engine helpers\n\n`ah-chromiumd`, `ah-webkitd`, and `ah-ladybirdd` are profile servers and embed\nhelpers. Prefer opening pages through Terminal / `ahweb`. Reach for the\nhelpers only when you are debugging packaging or engine paths.\n\n## A multi-pane day\n\nHere is the loop 0.1.17 is built for.\n\n1. Open Astrohacker Terminal.\n2. Pane A: your coding agent—Claude Code, Codex, Grok, OpenCode, Pi, whatever\n   you actually use.\n3. Pane B: `ahsh` in the repo the agent is touching.\n4. Pane C: `ahed` on the file that just changed.\n5. Pane D: `ahweb http://localhost:3000` (or the docs, or the provider\n   dashboard) with `--profile work` if you want login isolation.\n\nWhen the agent asks you to verify a UI, you do not leave. When the docs site\nand the app disagree, you split panes. When WebKit and Chromium disagree, you\nchange `--browser` instead of installing a second browser lifestyle.\n\nThat is the product: **agents, code, and real web in one window.**\n\n## What 0.1.17 is not\n\nShort list so we keep trust:\n\n- Not a promise that every site is perfect in every engine\n- Not Gecko parity\n- Not Wallet\n- Not a multi-SKU store of “Shell Inc.” and “Editor Inc.”\n- Not finished\n\nIt is a workbench release for people who install from a tap and send bug\nreports with stack traces.\n\n## What to do next\n\nInstall:\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nThen open Terminal, split a pane, and run:\n\n```bash\nahweb example.com\n```\n\nDocs for components and engines live under\n[astrohacker.com/docs](https://astrohacker.com/docs)—Terminal, Shell, Editor,\nWeb, Chromium, WebKit, Ladybird.\n\nIf you are already living with coding agents on Apple silicon, this is the\nversion to try: **0.1.17**, one Homebrew cask, real browsers where your agents\nalready are.\n",
            "url": "https://astrohacker.com/blog/2026-07-13-astrohacker-0-1-17",
            "title": "Astrohacker 0.1.17: Real Browsers in Your Terminal",
            "summary": "Multi-engine, multi-profile panes next to your shell on Apple silicon—install with Homebrew and keep coding agents, docs, and dashboards in one window.",
            "date_modified": "2026-07-13T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-12-why-gecko-is-the-hard-one",
            "content_html": "\nAstrohacker Terminal runs **real browser engines** in the same window as your\nshell: Chromium, WebKit, Ladybird today, and Gecko on the long path. Same\nprotocol. Same “open a page beside the terminal” idea. Very different amount of\npain.\n\nThis is not a dunk on Firefox. Gecko is excellent software. It is also the\nengine whose **desktop embedding story** was never written for people like us.\nWe learned that the expensive way—research, builds, experiments, and a few\nhonest dead ends.\n\n## What “supported” means here\n\nWe are not shipping a Firefox skin. We need the same **product shape** the\nother engines already have:\n\n- A page loads in a **terminal pane**, not a random window somewhere on the\n  desktop.\n- Geometry comes from the terminal (resize the pane → the web surface follows).\n- Input and focus go into that page.\n- Launch is named and boring: pick the engine, get `BrowserReady`, keep going.\n\nProtocol scaffolding is necessary. It is not sufficient. A helper that speaks\nthe right messages while the only visible UI is a floating Firefox chrome window\nis **progress**, not parity.\n\n## Four engines, four host stories\n\n- **WebKit** — You host a real `WKWebView` (`NSView`). Closest to “put a view\n  in a window.”\n- **Chromium** — Content API / known fork patterns. Heavy, but **designed** to\n  be hosted.\n- **Ladybird** — LibWeb + their shell. Young; hard work, but **your**\n  architecture.\n- **Gecko** — No official desktop embed equivalent. You reverse-engineer\n  **Firefox**.\n\nWebKit wins the “easy” prize for a reason: the modern API _is_ a view. Input\noften behaves like any other AppKit first responder. Compositing is “the view\nis there.”\n\nChromium is a different kind of hard: giant tree, multi-process, custom\ncompositor bridges (on our stack, the CAContext / host-layer story). But\nChromium still has a **first-class content hosting** culture. You are not\npretending to be Chrome’s UI; you are attaching to an embedding surface people\nexpect to fork and ship.\n\nLadybird is hard because the engine is still growing—not because Mozilla (or\nanyone) removed the front door.\n\nGecko is hard because **the front door moved**.\n\n## The missing front door\n\nFor years people said “embed Gecko with libxul / XPCOM.” That was a real story\nonce. Product reality now is different:\n\n- The modern, supported embed product is **GeckoView** — and it is\n  **Android-only**.\n- Desktop Firefox is optimized to be **Firefox**, not a content widget you drop\n  into someone else’s process.\n- Out-of-tree “call the old embedding exports and link” is a nostalgia path. We\n  tried it. It **failed** as a practical route for our binary.\n\nSo the work becomes: live in the **Firefox tree**, boot enough of **XRE /\nXPCOM**, and find whatever internal surfaces still create a browser context\n(`nsIWindowlessBrowser` and friends), all without a vendor promise that those\nhooks stay stable for third parties.\n\nThat is a research program with a build farm attached—not a weekend wrapper.\n\n## Compositing is a second cliff\n\nEven after you can load a URL, you still have to **show** it in a pane.\n\nChromium’s macOS story in our stack leans on a compositor path we already\nunderstood: cross-process layers, hostable surface IDs, a known dance into the\nterminal.\n\nGecko’s modern path is **WebRender → IOSurface-backed native layers**, with\ncross-process handoff that is **not** “the same as Chromium’s CAContext\ntrick.” Headless mode makes this worse: Firefox’s headless path is happy to\n**disable GPU compositing**, which is exactly what you do _not_ want if the\ngoal is a live pane, not a software screenshot.\n\nPreferred long-term shape (from our architecture notes): something like an\n**NSView overlay** or a **shared surface drawn into a Ghostboard-owned view**.\nNeither is free. Both require owning the host surface, not just moving a\nforeign window around with accessibility APIs.\n\n## What we already proved\n\nWe did not only read source. We built Nightly, shipped an `ah-geckod` helper,\nspoke the TermSurf protocol, and ran real loads.\n\nRough scoreboard:\n\n1. **Full Firefox build** from a monorepo checkout — works (expensive, real).\n2. **Process-windowless** load with TabReady / URL / title callbacks — works\n   (in-tree).\n3. **Ghostboard launch** with named `gecko` — works.\n4. **Visible window + geometry follow** (process chrome aligned to the pane\n   via platform geometry) — works as a **milestone**.\n5. **Out-of-tree classic embedding init** — **fail**.\n6. **True pane-hosted webview + real input/focus like the other engines** —\n   **not done yet.** That is the open product work.\n\nThe milestone matters. It proves Gecko can live in our multi-engine world at\nall. It also tempts a bad conclusion: “the window tracks the pane, ship it.”\nThat is how you quietly redefine “supported.”\n\nA pane-**aligned** Firefox window is not a pane-**hosted** webview. Clip,\nz-order, focus, and input all tell on you.\n\n## Protocol complete ≠ product complete\n\nOur protocol rule for engines is strict: every relevant message is either\nimplemented or **explicitly** unsupported—no silent ignores, no hangs.\n\nGecko can satisfy that rule while mouse and key still log “until embed.” That\nis honest scaffolding. It is also a neon sign: the hard part is still the\n**host surface and input path**, not another protobuf row.\n\nIf an engine only loads pages in a sidecar window and cannot take TermSurf\ninput, it is not “the same as WebKit in the terminal.” It is a demo of intent.\n\n## Why we still want it\n\nStrategic reason, not nostalgia: a multi-engine terminal that only runs\nChromium-family and WebKit is already powerful. Adding **Gecko** means the same\nworkbench can exercise the last major production browser lineage on the open\nweb—same session habits, different engine bugs, different layout, different\nreality check.\n\nLadybird is the future-facing independent engine. Gecko is the production\nFirefox lineage. Both belong in the set if the claim is “major engines,” not\n“engines that were convenient to wrap.”\n\n## What “done” has to mean next\n\nWe opened a follow-on bar that forbids the soft landing:\n\n- Content is **hosted in or composited into** the terminal pane surface.\n- Geometry is driven by TermSurf / the board—not only by chasing a foreign\n  top-level window.\n- Input and focus affect the page.\n- Launch still looks like the other engines from the user’s point of view.\n\nProcess chrome can stay a temporary ladder rung. It cannot be the definition of\ndone.\n\n## Closing\n\nGecko is the hard one because **embedding was never the product on desktop**,\nthe **compositor contract is foreign** to the Chromium path we already ship,\nand **honest intermediate wins** (windowless load, named launch, a visible\nwindow that follows the pane) look deceptively like finish lines.\n\nWebKit gives you a view. Chromium gives you a hosting culture. Ladybird gives\nyou a tree you can still shape. Gecko gives you Firefox—and then the work of\nmaking Firefox behave like a webview inside someone else’s window.\n\nWe are doing that work on purpose. The easy engines make the product real. The\nhard engine makes the product complete.\n",
            "url": "https://astrohacker.com/blog/2026-07-12-why-gecko-is-the-hard-one",
            "title": "Why Gecko Is the Hard One",
            "summary": "Chromium, WebKit, and Ladybird can sit in a terminal pane. Gecko can too—eventually. Here is why Firefox is the awkward fourth engine, what we already proved, and what still counts as real support.",
            "date_modified": "2026-07-12T16:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-07-11-unifying-under-astrohacker",
            "content_html": "\nWe used to open [astrohacker.com](https://astrohacker.com) like a trade-show\nbooth map.\n\nSeven tiles. Seven domains. TermSurf, Shannon, NuTorch, EarthBucks, KeyPears,\nWebBuf, RSS Anyway—each with a formula line and a status badge. That was honest\nabout how the work got built. It was a terrible front door.\n\n**We are folding the whole portfolio under the Astrohacker name.**\n\nNot done. Underway. Some of it already ships as Astrohacker. Some of it still\nwears the old labels while we merge code, packaging, and product surfaces.\nExpect legacy sites to lag. The direction is set.\n\n## What you can install today\n\nThis part is not aspirational. One Homebrew cask on Apple silicon macOS:\n\n```bash\nbrew tap astrohackerlabs/astrohacker\nbrew trust astrohackerlabs/astrohacker\nbrew install --cask astrohacker\n```\n\nThat ships:\n\n- **Astrohacker Terminal** — multi-engine browsers (Chromium, WebKit, Ladybird)\n  in the same window as your shell.\n- **Astrohacker Shell** — ships with Terminal.\n- **Astrohacker Editor** — ships with Terminal.\n- **Astrohacker Web** — `ahweb`: open a real engine in a pane.\n\nOne brand. One download into `/Applications`. Pieces live under [docs](/docs),\nnot as four separate storefronts.\n\nThat is the first unification that matters: the **desktop workbench** is already\nAstrohacker.\n\n## What still gets folded in\n\nThe old grid was bigger than the workbench. Those projects are still company\nwork. Over time they get **Astrohacker + a second word** and land in the company\nrepos and release trains—not forever as peer consumer brands on the homepage.\n\nWorking names below are **aspirational**. **Final public names are TBD.** This\nis not a launch checklist.\n\n**Already folded or shipping under Astrohacker**\n\n- **TermSurf** → **Astrohacker Terminal**. TermSurf stays the protocol name in\n  code and history.\n- **Shannon** → **Astrohacker Shell**. You will still see Shannon in lineage\n  notes.\n\n**Next (names drafts only)**\n\n- **NuTorch** → Astrohacker Torch (TBD) — GPU tensors from the shell.\n- **EarthBucks** → Astrohacker Cash (TBD) — electronic cash / EBX.\n- **KeyPears** → Astrohacker Keys (TBD) — identity, secrets, encrypted\n  messaging.\n- **WebBuf** → Astrohacker Buf (TBD) — buffers and crypto libraries.\n- **RSS Anyway** → Astrohacker Feed (TBD) — open-web feed aggregation.\n\nOther experiments (Rickbait, and whatever we invent next) get the same rule when\nthey are ready: Astrohacker _something_, name TBD, merge when the product story\ncatches up.\n\n## What “folded in” actually means\n\nNot a logo sticker.\n\n- **Brand** — users eventually meet Astrohacker first, not a maze of half-related\n  domains.\n- **Code and packaging** — projects move into company repositories and release\n  trains where it makes sense.\n- **Product surfaces** — Terminal is the desktop wedge. Wallet, keys, cash, and\n  web services still point at the long-term **Astrohacker Economy** idea—agents\n  and humans with identity and value under human control—without claiming those\n  surfaces are fully renamed or shipped under new names today.\n\nIf keypears.com still says KeyPears tomorrow, that is expected. Cutover is\nproject by project.\n\n## Why bother\n\nA product grid flatters the builder. One company brand serves the user.\n\nWe build for people who live in the terminal and the browser—often with AI\ncoding agents in the loop. The workbench for that is Astrohacker Terminal. Money,\nkeys, libraries, and web tools belong under the same roof, not as seven competing\nhomepage cards.\n\n## What to do\n\n- **Use what ships:** install [Terminal](/), read the [docs](/docs).\n- **Expect lag:** old domains and names stick around during the merge. Draft\n  names above can change.\n- **Follow along:** [blog](/blog), [Discord](https://discord.gg/S539YVq7sr),\n  [GitHub](https://github.com/astrohackerlabs).\n\nWe are not saying the merge is finished. We are saying it has started—with a\nTerminal that already works—and the rest of the portfolio is coming under\nAstrohacker as we go.\n",
            "url": "https://astrohacker.com/blog/2026-07-11-unifying-under-astrohacker",
            "title": "Folding the Portfolio into Astrohacker",
            "summary": "We used to be a product mall. Terminal, Shell, Editor, and Web ship under Astrohacker today. Everything else is folding in—names still TBD.",
            "date_modified": "2026-07-11T18:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-06-01-building-software-while-you-sleep",
            "content_html": "\nWe don't solve software issues at Astrohacker anymore. We specify them. The\nissue gets a clear goal, explicit verification criteria, and a set of\nguardrails — and then a command runs the rest. One agent designs experiments,\nwrites the code, and runs the tests. A second agent reviews its work\nadversarially at every step. The loop runs end to end, and the software gets\nbuilt while we sleep.\n\nThis is not a demo or a roadmap. It is how the entire portfolio ships today —\nthe methodology Astrohacker founder [Ryan X.\nCharles](https://ryanxcharles.com) developed across [TermSurf](https://termsurf.com),\n[Shannon](https://shannonshell.com), [KeyPears](https://keypears.com), and\n[EarthBucks](https://earthbucks.com), and now runs as a single automated\npipeline. We've crossed into the automated software development age, and the\ncommit logs are public.\n\n## The lifecycle, end to end\n\nHere is the whole loop, with no human in the middle of it.\n\nA goal is written down — not a plan, a goal. What \"solved\" means is stated as\nexplicit verification criteria. The guardrails go next: which tests to write,\nwhich linters and type checkers must pass, which code patterns the solution has\nto follow. Then the machine takes over. It designs one experiment. A second\nagent reviews that design. If the design passes, the first agent implements it,\nruns the verification, and records the result. Then it designs the next\nexperiment, informed by what the last one taught it. The cycle repeats —\ndesign, review, implement, verify, record — until the verification criteria\npass and the issue is closed.\n\nThat is the fully automated software development lifecycle. Specification in,\nshipped software out, and the iteration in between belongs to the machine.\n\n## The goal is the whole job\n\nWhat's left for a human is the front of the loop, not the inside of it. The\nwork is writing the issue well enough that solving it becomes mechanical: a\nclear description of the goal, concrete criteria for what counts as done, and\nthe guardrails that keep the solution honest. Once that is written down — in the\nissue itself or in the project's `AGENTS.md` — the job is essentially over. We\nare not the ones who solve the issue. We are the ones who define it precisely\nenough that the solving can be automated. This is the front edge of a shift\nthe founder has called [setting the goal and walking\naway](https://ryanxcharles.com/blog/2026-06-01-set-the-goal-walk-away).\n\n## Experiments, not plans\n\nThe loop does not march through a plan. It runs experiments. Each experiment\neither fully solves the issue, partially solves it, or fails — and failure is\nfine, because a failed experiment is progress. It means something was poorly\nunderstood, and now it isn't. Every result is logged whether it passes or\nfails, so the record narrows toward the goal with each iteration. The\ndocumentation is the primary artifact; the code is what happens when an\nexperiment returns a pass.\n\nThis is [research-driven\ndevelopment](https://ryanxcharles.com/blog/2026-03-08-research-driven-development),\nand it is the substrate the automation runs on. You never list the experiments\nup front, because the result of experiment N is what tells you what experiment\nN+1 should be. The lab notebook stays current without effort because the same\nagents that write the code write the notebook — which is exactly what makes the\nnotebook cheap enough to keep, and what makes automating the loop possible at\nall.\n\n## Adversarial review is the keystone\n\nThe thing that makes an unattended loop trustworthy is a second agent trying to\ntear the work apart. It is not enough for an agent to write and pass its own\ntests — marking your own homework is how slop ships. So a separate agent\nperforms an adversarial review at the two stages that matter: the experiment\n_design_ must pass before any code is written, and the _result_ must pass before\nthe next experiment begins.\n\nThe reviewer doesn't need to be a different model. It needs to come at the work\ncold — a fresh context, not a fork. A clean built-in subagent works; so does a\ncall out to a separate CLI tool. Different context is all you need, as long as\nboth agents are state-of-the-art. That cold second look is what keeps an\novernight run from drifting, and it is the difference between an automated\npipeline you can trust and one you have to babysit.\n\n## The receipts\n\nThe claim is falsifiable, and the proof is in the repos. With this flow we\nadded full PDF support to TermSurf — a GPU-accelerated Chromium browser inside\nthe terminal — in about a day; rendering PDFs through a Chromium embedder by\nhand would have cost months. PDFs now render inline, scroll, select, and print.\nAnd as this post goes out, the loop is doing something no one would attempt by\nhand: porting Ghostty from Zig into Rust, one terminal subsystem at a time. That\nissue is over a hundred experiments deep, nearly all passing, with hundreds of\ncommits landed in a matter of days — tabstops, page storage, selection,\nformatters, escape-sequence handlers — each one designed, reviewed, implemented,\ntested, and reviewed again, with no hands on the keyboard. Click into the\n`issues/` folder of any Astrohacker repo and you are reading the actual\nengineering history, not a sanitized summary.\n\n## Why now\n\nThis works today because three things converged at once. The models finally\ncrossed the quality bar where their code is better than what most engineers\nwrite by hand. The tooling grew goal-level orchestration, so a whole issue can\nbe handed off in a single command. And the best practices — tests, explicit\nverification, adversarial review — matured into a loop that produces output you\ncan actually trust. None of these alone is enough. Together they mean the\nsoftware development lifecycle, end to end, can run without a human inside it.\n\nSo that's how Astrohacker builds now. Set the goal. Hack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-06-01-building-software-while-you-sleep",
            "title": "Building Software While You Sleep: The Fully Automated Software Development Lifecycle",
            "summary": "Every tool in the Astrohacker portfolio is now built the same way: a goal is specified, one agent solves it, a second agent keeps it honest, and the loop runs end to end with no human in it.",
            "date_modified": "2026-06-01T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-05-18-earthbucks-2-network-plan",
            "content_html": "\nEarthBucks 2.0 is becoming a working system.\n\nThe last update was about progress: Rust mines, database state, transaction\nvalidation, Merkle ordering, mine-to-mine networking, mining-pool substrate, and\nthe start of the new EarthBucks app.\n\nA wallet opens and checks `mine1.earthbucks.com` for headers and proofs.\n\nA browser miner logs into `earthbucks.com`, gets work from the pool, and submits\nshares without talking directly to a mine.\n\nA website embeds Compucha, asks a visitor for proof-of-work instead of a\ncaptcha, and that work can eventually point at the same EarthBucks mine network.\n\nThat is the split EarthBucks 2.0 is building toward: **mines settle, pools\ncoordinate work, wallets hold money, and apps create demand.**\n\nThe old model put too much into one place. The new model gives each part a job.\n\n## The first mine network\n\nEarthBucks 2.0 will launch with at least three production mines:\n\n- `mine1.earthbucks.com`\n- `mine2.earthbucks.com`\n- `mine3.earthbucks.com`\n\nThose names are not decoration. In EarthBucks, mines are identified by domain\nnames. A mine is a professional network participant: it validates transactions,\nmaintains UTXO state, synchronizes transaction order with peer mines, accepts\nsolved work, and participates in finality.\n\nThis is different from Bitcoin's anonymous public node model. EarthBucks mines\nare known services with domain identities. At launch, the first mines will be\noperated by Astrohacker. In the future, mines may live at other domains and may\nbe operated by other businesses.\n\nThree known mines are enough to stop pretending the network is a single server.\n\n## Mines are not pools\n\nThe most important product change in EarthBucks 2.0 is that mines and pools are\nseparate concepts.\n\nIn the early EarthBucks design, a mine was basically what Bitcoin would call a\nmining pool. The same service handled users, miners, validation, accounting, and\nnetwork behavior.\n\nThat was useful for getting EarthBucks 1.0 shipped. It is not the right shape\nfor EarthBucks 2.0.\n\nIn EBX2, a **mine** is a validating network service. It owns consensus-facing\nbehavior. It does not need to be a public consumer app.\n\nA **pool** coordinates proof-of-work. It asks mines for work templates,\ndistributes work to miners, tracks shares, and submits solved work back to the\nmine that issued it.\n\nThe mine is the settlement layer. The pool is the economic coordinator for\nhashpower.\n\nThose should not be the same thing.\n\n## earthbucks.com remains the first pool\n\n`earthbucks.com` will continue to be the main EarthBucks app.\n\nIt will also continue to be the first EarthBucks mining pool.\n\nInternally, the new app is currently called `www-pool`. That is an engineering\nname, not the public product name. The old `www-earthbucks-com` app needs to\nkeep running while the new app is built, so the new project needs a different\ndirectory and package name.\n\nThe public destination is still EarthBucks.\n\nThe new app will eventually live at `earthbucks.com`. During development, it may\nbe useful to run it somewhere else, but the product boundary is clear:\n\n- `earthbucks.com` is the wallet, pool, docs, and status app.\n- the mine subdomains are validating network services.\n\nThe app is not a mine.\n\nThat distinction matters because it lets more pools exist later without making\nevery pool a consensus participant.\n\n## Wallets connect with SPV\n\nUsers should not need to run mines.\n\nEarthBucks wallets should be able to connect to mines with SPV-style\nverification. A wallet can submit transactions, verify headers and Merkle\nproofs, inspect transaction status, and show finality without becoming part of\nthe validating mine network.\n\nThe EarthBucks app will include a wallet. That is the default user experience.\n\nBut EarthBucks 2.0 should also support third-party wallets. If someone wants to\nbuild a different wallet UI, a mobile wallet, a terminal wallet, or a wallet\ninside another product, they should be able to connect to the mines and verify\nwhat they need to verify.\n\nThe user-facing app and the network should not be welded together.\n\nThat is the point of having mines, pools, and wallets as separate roles.\n\n## More pools are coming\n\nAt launch, the first pool is `earthbucks.com`.\n\nIn the future, there should be more pools.\n\nThe most likely second pool is Compucha.\n\nCompucha is a proof-of-work captcha replacement. Instead of asking users to\nclick traffic lights, decipher distorted text, or train someone else's image\nclassifier for free, a website can ask the user to perform a small amount of\nproof-of-work.\n\nThe current Compucha direction is already useful: an embeddable iframe, a\nchallenge endpoint, a verification endpoint, WebGPU mining when available, and a\nWASM fallback when it is not.\n\nThe EarthBucks direction makes it better.\n\nIf proof-of-work is needed to log into a website, that work should not merely\nvanish. It should be able to mine EarthBucks. The user proves they spent real\ncomputation, the website gets a better abuse filter than a captcha, and the work\ncan participate in an actual cash network.\n\nProof-of-work is better than captchas.\n\nEarning money is better than proof-of-work that goes nowhere.\n\nThat is why pools should be separate from mines. `compucha.com` can become a\npool with a totally different product surface from `earthbucks.com`, while still\ntalking to the same EarthBucks mine network.\n\n## KeyPears is the protocol layer\n\nEarthBucks 2.0 is also being built in the same direction as KeyPears.\n\nKeyPears is the identity, messaging, and secret-exchange layer of the\nAstrohacker portfolio. It uses domain-based federation, cryptographic\nauthentication, and proof-of-work where appropriate.\n\nEarthBucks needs the same style of internet-native plumbing.\n\nThe plan is for EarthBucks services to use KeyPears-compatible protocol ideas so\nusers and apps can send authenticated messages, transaction data, and service\nrequests across compatible domains.\n\nThat matters because EarthBucks is not just one website. It is a network:\n\n- mines at domain names;\n- pools at domain names;\n- wallets that connect to mines;\n- apps that create reasons to earn and spend EBX;\n- services that need to exchange signed messages and transactions.\n\nKeyPears gives that world a common protocol direction.\n\n## What users can expect\n\nEarthBucks 2.0 is not live yet, and some implementation details will keep\nchanging as the system hardens.\n\nBut the direction is no longer fuzzy.\n\nThe first production network has multiple mines. Wallets connect to mines\nwithout becoming mines. The EarthBucks wallet ships in the app, and third-party\nwallets should be able to use the same network.\n\nPools become a product layer. `earthbucks.com` is first. Compucha is the next\nserious candidate: a proof-of-work captcha replacement that can turn login\nfriction into useful mining.\n\nKeyPears-compatible service communication ties the pieces together so the\nAstrohacker projects do not become isolated islands.\n\nAnd continuity still matters. EarthBucks 2.0 is not a new genesis block, not a\nbalance reset, and not a new coin. It is the next network architecture for\nEarthBucks.\n\n## The simple model\n\nMines settle.\n\nPools coordinate work.\n\nWallets hold money.\n\nApps create demand.\n\nThat is the EarthBucks 2.0 network plan.\n\nBuild the mines. Connect the pool. Open the wallet. Let other apps plug in.\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-05-18-earthbucks-2-network-plan",
            "title": "The EarthBucks 2.0 Network Plan",
            "summary": "EarthBucks 2.0 separates mines from pools, launches with three production mines, supports SPV wallets, and opens the path to new proof-of-work applications.",
            "date_modified": "2026-05-18T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-05-04-astrohacker-begins-earthbucks-2-0",
            "content_html": "\nAstrohacker has begun work on [EarthBucks 2.0](https://earthbucks.com/blog/2026-05-03-beginning-work-on-earthbucks-2-0).\n\nThis is not a new coin. It is not a new genesis block. It is not a balance reset. It is the next major engineering phase for EarthBucks: the phase that turns the current single-mine system into a real peer-to-peer mine network, connects EBX to Bitcoin Cash, and gives users a self-custodial path to trade between them.\n\nEarthBucks is the money layer of the Astrohacker portfolio. TermSurf is about the interface. KeyPears is about identity, secrets, and messaging. EarthBucks is about electronic cash.\n\nThe cash part now gets serious.\n\n## What 2.0 means\n\nEarthBucks 2.0 has three practical goals:\n\n1. Build the peer-to-peer mine network.\n2. Add a Bitcoin Cash wallet.\n3. Enable atomic swaps between EBX and BCH.\n\nThe mine network is the foundation. In EarthBucks, mines are not anonymous hobby nodes. They are accountable services at domain names. They validate transactions, maintain chain state, build blocks, synchronize with other mines, and form the settlement layer of the system.\n\nThe first 2.0 mines will be operated by Astrohacker. That is the right starting point. The goal is not to pretend the network is decentralized before the software exists. The goal is to make the system correct, observable, operational, and useful, then expand from there.\n\nBitcoin Cash is the liquidity path. BCH is already electronic cash with users, wallets, exchanges, and a market price. If EBX can be swapped with BCH without a centralized custodian, EBX gets a real path to price discovery.\n\nThat is the thesis: build the real network, connect it to liquid cash, and let EBX find a market.\n\n## What has started\n\nThe first work is not a new screen. It is consensus code.\n\nOver the past few days, the EarthBucks 2.0 work has moved through a long sequence of implementation issues. The core direction is now clear: server-side mines should be built on a Rust consensus library, with byte-for-byte parity against the existing TypeScript implementation where the current chain behavior matters.\n\nThat work now covers the substrate mines need:\n\n- keys, addresses, public key hashes, and signatures;\n- Blake3 hashing and deterministic ECDSAb3 signing;\n- serialization primitives, VarInts, and 256-bit target numbers;\n- headers, target calculation, and canonical difficulty-adjustment math;\n- transactions, scripts, standard templates, and mint transaction shapes;\n- the script interpreter;\n- transaction verification;\n- Merkle trees, Merkle proofs, blocks, and ID wrappers;\n- mint transaction validation and block acceptance;\n- Pow5 header work validation.\n\nThis is the part of a cryptocurrency that cannot be approximate. A mine cannot \"mostly\" parse a header. A transaction verifier cannot \"kind of\" agree with the wallet. Difficulty math cannot depend on whatever two floating-point implementations happen to do this week. Work validation cannot accept a header because the shape looks plausible.\n\nConsensus software is boring until it fails. Then it is the whole product.\n\n## Why this belongs at Astrohacker\n\nAstrohacker exists to make the projects reinforce each other.\n\nEarthBucks is not an isolated blockchain experiment. It belongs next to the rest of the portfolio:\n\n- [TermSurf](https://termsurf.com) is a better interface for people who live in terminals.\n- [Shannon](https://shannonshell.com) is a shell built for real command-line work.\n- [KeyPears](https://keypears.com) is identity, messaging, and secrets under user control.\n- EarthBucks is money for that world.\n\nThe connection is not \"crypto\" as a category. The connection is infrastructure. Keys, addresses, signatures, feeds, shells, browsers, messages, payments. The portfolio is a set of tools for people and software that need to act on the internet without asking permission from five unrelated platforms.\n\nEarthBucks 2.0 is how the money piece grows up.\n\n## What 2.0 is not\n\nEarthBucks 2.0 is not a disruption to existing users. The 1.0 chain history is preserved. Existing balances, keys, and addresses must continue to work.\n\nIt is also not a post-quantum rewrite. EarthBucks already has practical quantum-resistance properties from its public-key-hash design, key non-reuse, and fast settlement model. Post-quantum cryptography matters, but forcing immature large-key primitives into 2.0 would be the wrong trade.\n\nIt is not the release for every advanced feature. Tokens, broader smart contracts, a new proof-of-work function, unlimited script usage, and third-party mine operation can all wait. They may matter later. They are not the next bottleneck.\n\nThe next bottleneck is the real network.\n\n## What comes next\n\nThe next phase is still engineering, not theater.\n\nThe remaining work includes the 2.0 mine database schema, inter-mine synchronization, the first Astrohacker-operated mine deployment, the Bitcoin Cash wallet, the atomic swap protocol, and the exchange interface.\n\nSome details will change. The first mine domains may change. Storage choices may change. The swap design needs its own careful work. That is normal. The direction is settled.\n\nEarthBucks 2.0 means Rust mines, domain-based peer-to-peer consensus, Bitcoin Cash liquidity, and self-custodial EBX/BCH swaps.\n\nAstrohacker builds the products. EarthBucks moves the money.\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-05-04-astrohacker-begins-earthbucks-2-0",
            "title": "Astrohacker Begins EarthBucks 2.0",
            "summary": "EarthBucks 2.0 has begun: Rust mines, peer-to-peer consensus, Bitcoin Cash liquidity, and self-custodial EBX/BCH swaps.",
            "date_modified": "2026-05-04T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-04-27-keypears-hybrid-post-quantum",
            "content_html": "\n[KeyPears](https://keypears.com) is now hybrid post-quantum. Every message, every signature, every account — by default, on the only code path.\n\nThis is not a feature flag. It is not an enterprise tier. It is not a compatibility mode for cautious users. The protocol's cryptographic spine has moved, and the safe path is now the normal path.\n\n## What \"hybrid\" means here\n\n| Purpose          | Classical      | Post-quantum | Construction            |\n| ---------------- | -------------- | ------------ | ----------------------- |\n| Signatures       | Ed25519        | ML-DSA-65    | Both required           |\n| Key agreement    | X25519         | ML-KEM-768   | Shared secrets combined |\n| Symmetric crypto | AES-256-GCM    | —            | Unchanged               |\n| Hash & KDF       | SHA-256 family | —            | Unchanged               |\n\nEach message is encrypted with a key derived from _both_ an X25519 Diffie-Hellman exchange and an ML-KEM-768 encapsulation, combined through HKDF. Each message is signed with _both_ an Ed25519 signature and an ML-DSA-65 signature over the same canonical envelope. Recovering plaintext or forging a signature requires defeating both halves.\n\n## Why hybrid, not pure post-quantum\n\nML-KEM and ML-DSA are NIST-standard and have been through years of public analysis. But they don't have the multi-decade deployment history of elliptic curves. New cryptography is _new_.\n\nHybrid hedges in both directions:\n\n- If a fault-tolerant quantum computer breaks elliptic curves, the post-quantum half still protects you.\n- If a serious flaw is found in the post-quantum algorithms, the classical half still protects you.\n- If both hold up, the construction is stronger than either alone.\n\nThis is the conservative call, not the exciting one. The goal is not novelty. The goal is defensibility.\n\n## What changed for users\n\nMostly nothing visible. You still have a `name@domain` address. You still sign in. You still send messages and store secrets in the vault. Federation still works through `.well-known/keypears.json`.\n\nUnder the hood each account now holds four private keys instead of one — Ed25519, X25519, ML-DSA-65, ML-KEM-768 — all client-side encrypted under a key derived from your password. The server still sees only ciphertext.\n\nThe tradeoff is size: post-quantum keys and signatures are larger than their elliptic-curve counterparts. KeyPears moves messages, credentials, and notes — not video — so the extra kilobytes are a good trade.\n\n## Why this is an Astrohacker move\n\nOne of the through-lines of the [Astrohacker portfolio](/blog/2026-04-13-introducing-astrohacker) is that **cryptography is plumbing, not a product category**. EarthBucks is the same idea applied to money; KeyPears applies it to identity, secrets, and messaging.\n\nHybrid post-quantum on the default path is what \"plumbing\" actually looks like. Not a checkbox, not a tier, not a \"secure mode\" — just the baseline. The user doesn't choose it because the user shouldn't have to.\n\nThe baseline should keep moving up. This is one step.\n\n## What it doesn't fix\n\nIt doesn't make a compromised device safe. It doesn't add forward secrecy to stored messages — KeyPears keeps ciphertext around so users can recover history across devices, which is a deliberate simplicity tradeoff. It doesn't make implementation bugs impossible.\n\nFor the full protocol description, the construction details, and the parts that didn't fit here, read the [KeyPears post on this change](https://keypears.com/blog/2026-04-26-keypears-is-hybrid-post-quantum) and the [whitepaper](https://keypears.com/whitepaper.pdf).\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-04-27-keypears-hybrid-post-quantum",
            "title": "KeyPears Goes Hybrid Post-Quantum",
            "summary": "Every KeyPears message and signature now combines classical and post-quantum cryptography by default.",
            "date_modified": "2026-04-27T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-04-24-introducing-rss-anyway",
            "content_html": "\nThe open web still publishes. People are still writing blogs, shipping\nchangelogs, pushing releases, posting essays, uploading videos, dropping papers\non arxiv. The shortage isn't content. The shortage is a good way to read it.\n\nRSS Anyway is an attempt at that good way. It's a feed aggregator that discovers\nblogs automatically, generates feeds for sites that don't have them, and now\nlets you add anything else you want to follow.\n\nIt's in alpha, live at [rssanyway.com](https://rssanyway.com).\n\n## What it is\n\nRSS Anyway reads [Hacker News](https://news.ycombinator.com) as a signal layer,\nclassifies every URL it sees, and either finds a native RSS/Atom/JSON feed or\ngenerates one by scraping. The result is a hot-ranked homepage of the latest\nposts from across the open web — a lot of sites you already know, and a lot you\ndon't. Built on Bun, TanStack Start, and MySQL.\n\n## Three things that make it different\n\n### It generates feeds for sites that don't have them\n\nA lot of the open web doesn't expose RSS at all. RSS Anyway's classifier handles\nGitHub repos, YouTube channels, Discourse forums, arxiv authors, and generic\nstatic blogs — walking paths, scanning links, extracting sitemaps, reading index\npages. If a site publishes on any kind of schedule, we'll usually find a way to\nturn it into a feed. Each feed is also re-exported as RSS, Atom, and JSON, so\nyou can read it in any client.\n\n### Follow anything, literally\n\nNew this week: sign in, hit the `+` button in the bottom-right, paste any URL.\nIf we can classify it, you see a preview of the feed and a **Follow** button. If\nwe can't, we'll tell you exactly why. Either way, the feed joins the aggregator\nfor everyone — the index is user-extensible by design.\n\n### Sign in with KeyPears\n\nNo passwords, no OAuth, no signup flow. Type your KeyPears address — something\nlike `you@example.com` — sign once with your key, and you're in. Use the public\n[keypears.com](https://keypears.com) node or host your own. RSS Anyway discovers\nyour node via `.well-known`, verifies the signature, and creates your account on\nthe spot. Federated identity, cryptographically checked, zero friction.\n\n## What you can do right now\n\n- **Browse hot (`/`) and new (`/new`)** — Reddit-style ranking over the entire\n  index, or reverse-chronological if you just want the firehose.\n- **Follow feeds or whole domains** — hover any domain, click follow. Your\n  subscriptions show up at `/following`.\n- **Submit any URL at `/submit`** — if it's classifiable, it's indexed in\n  seconds.\n- **Browse by domain** at `/domains/[domain]` — see every feed we've found for a\n  site, and every recent item.\n\n## Why this exists\n\nThe big algorithmic feeds optimize for engagement with their own network. RSS\nAnyway optimizes for access to the open web. The bet is that a decent aggregator\nof everything-that-publishes is more valuable in the long run than a great\ncurator of a walled garden. And the bet is that giving people a way to _add\ntheir own sources_ — instead of asking them to trust a team of editors — is how\nyou get there.\n\nIt's alpha. The classifier will get some sites wrong. The hot ranking will\nsometimes hot the wrong stuff. The sign-in flow assumes you know what KeyPears\nis. All of that will get better.\n\nIn the meantime: go sign in, follow a few domains, submit your favorite blog.\nTell us what we got wrong.\n\n[rssanyway.com](https://rssanyway.com).\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-04-24-introducing-rss-anyway",
            "title": "Introducing RSS Anyway",
            "summary": "A feed aggregator that starts with the open web — and lets you add anything else.",
            "date_modified": "2026-04-24T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        },
        {
            "id": "https://astrohacker.com/blog/2026-04-13-introducing-astrohacker",
            "content_html": "\nFor years I've been shipping projects under scattered banners — a blockchain here, a shell there, an encrypted messenger, a social-network joke that got out of hand. Each one had its own domain, its own repo, its own half-written about page. None of them had a home.\n\n**Astrohacker is that home.** It's the umbrella company for everything I build: a single brand for a portfolio of tools that all share one premise — that science and technology are how we explore and understand the universe, and that the best way to explore is to build.\n\nThis post introduces the portfolio.\n\n## The portfolio\n\n### [TermSurf](https://termsurf.com) — `TERMINAL + BROWSER`\n\nA protocol that embeds GPU-accelerated web browsers directly in your terminal. Type `web` and you're browsing in your shell. No window-switching, no context loss, no leaving the keyboard. Currently in alpha. → [termsurf.com](https://termsurf.com)\n\n### [Shannon](https://shannonshell.com) — `NUSHELL + BASH`\n\nA shell built on nushell with seamless bash compatibility. Press Shift+Tab to switch modes: structured data pipelines on one side, decades of muscle memory on the other, environment and working directory synced between them. Shannon is not AI-first and doesn't try to be — it's a real shell for real work. In beta. → [shannonshell.com](https://shannonshell.com)\n\n### [EarthBucks](https://earthbucks.com) — `ELECTRONIC CASH`\n\nA global electronic cash system. GPU-mined, instant finality, email-like addresses, 42 million EBX. A from-scratch blockchain built on the original Bitcoin premise — peer-to-peer electronic cash — adapted for an era where AIs are going to need to pay each other. Shipped 1.0. → [earthbucks.com](https://earthbucks.com)\n\n### [Rickbait](https://rickbait.com) — `FRONT PAGE`\n\nAn AI-powered clickbait generator, algorithmic feed, and advertising auction market. It is exactly as serious as it sounds, and exactly as serious as the rest of the web. Alpha. → [rickbait.com](https://rickbait.com)\n\n### [KeyPears](https://keypears.com) — `SECRET EXCHANGE`\n\nFederated encrypted messaging, a secret manager, and an authentication provider, in one project. The pitch is that your keys, your secrets, and your identity should live in one place you control — not scattered across five SaaS dashboards. Alpha. → [keypears.com](https://keypears.com)\n\n## The through-lines\n\nLooking at the portfolio as a whole, a few themes surface:\n\n- **The shell is the interface.** TermSurf, Shannon, and most of the development tooling I reach for live at the command line. The terminal is not a legacy interface — it's the most powerful UI we have, and it deserves better infrastructure.\n- **Cryptography is plumbing, not a product category.** EarthBucks and KeyPears both treat crypto as a primitive for solving a concrete problem — moving money, holding secrets — rather than as an end in itself.\n- **Play is allowed.** Rickbait is a joke, and it's also a real product with a real auction market. The jokes inform the serious work and vice versa.\n\n## What's next\n\nAstrohacker is a founder-led portfolio company, and 2026 is the year the portfolio starts pulling its weight commercially. Expect shipping cadence to pick up on all fronts, expect a few new projects to join the roster, and expect this blog to track it all.\n\nIf you want to follow along, this blog has [RSS](/blog/feed.rss.xml), [Atom](/blog/feed.atom.xml), and [JSON](/blog/feed.json) feeds. Pick your poison.\n\nHack the universe.\n",
            "url": "https://astrohacker.com/blog/2026-04-13-introducing-astrohacker",
            "title": "Introducing Astrohacker",
            "summary": "One umbrella for a portfolio of tools spanning shells, cash, messaging, and the absurd.",
            "date_modified": "2026-04-13T12:00:00.000Z",
            "author": {
                "name": "Ryan X. Charles",
                "url": "https://astrohacker.com"
            }
        }
    ]
}