Carbonyl

Chromium running inside a terminal. Fathy Boundjadj's browser (BSD-3-Clause, Rust + a patched Chromium headless shell) renders real web pages — JavaScript, WebAssembly, WebGL, WebGPU, audio, video, animation — into a text terminal, with no window server anywhere in the stack. It works over SSH and in a safe-mode console.

19,426★ / 580 forks / 90 open issues / 96 watchers, and last pushed 2024-07-01 — dormant for over two years, not archived. Figures read 2026-08-17 from the GitHub API. T2: the claims below are the project's own, but the artifact is a real browser build rather than a product page, and nothing here is selling anything.

What is actually novel

Every category this spoke keeps sorts browsers by who the user is or what the browser does for them. AI browsers add a model, agent-first browsers delete the interface because the user is software, privacy browsers subtract tracking, productivity browsers rearrange tabs. Carbonyl does none of that. The browsing is ordinary Chromium browsing.

What it changes is where the pixels go. The novelty sits entirely in the output surface, which is a fourth axis and the first source here to move along it. Practically that means: no compositor, no display server, no GPU context to acquire — so a browser becomes a thing you can run inside an SSH session on a headless box, which is a capability none of the other twelve browsers in this corpus has at any price.

The claims

"Starts in less than a second, runs at 60 FPS, and idles at 0% CPU usage." A terminal grid is a very small framebuffer, so 60 FPS into a character cell is a far easier target than 60 FPS into a 4K window — the numbers are plausible for exactly the reason they are not comparable to a desktop browser's. None of them is measured here, and the project publishes no methodology, no hardware and no baseline.

Architecture is two parts: libcarbonyl, a Rust core, and a modified Chromium headless shell that routes its output through it. Distribution is Docker, npm, or binaries for macOS and Linux on both amd64 and arm64. Tested on Debian, Ubuntu, Arch, macOS, Windows 11 and WSL. Building from source is stated as roughly an hour and about 100 GB of disk, which is the ordinary price of touching Chromium and is worth recording as the reason forks of it are rare.

Stated limitation: no fullscreen mode.

The opposite move from the engine-diversity thread

ladybird and falco-browser-engine are this spoke's answer to a web with three engines: build a new one, from scratch, at enormous cost. Carbonyl starts from the premise that the engine is settled and spends its effort on the surface instead — it is Chromium precisely so that WebGL and WebAssembly work on day one.

Read together, the three sources describe two different scarcity claims. Ladybird and Falco say the scarce thing is an independent implementation of the web platform. Carbonyl says the scarce thing is somewhere else to put it, and that rehosting the incumbent engine buys a capability no new engine will have for years. Neither argument refutes the other, and the spoke has been carrying only the first.

Dormant, at nineteen thousand stars

Two years and six weeks since the last push, 90 open issues, no archive notice. Nothing here says the project failed — a browser that renders to a terminal has a bounded feature list and may simply be finished for its author's purposes — but a Chromium fork is the worst possible artifact to leave unattended, because the upstream it patches ships a security release roughly every fortnight. Anyone running this today is running a two-year-old Chromium.

That is the third source this hub has logged in one day where a large star count sits on a repository nobody maintains, and the three fail differently: ai-marketing-claude was created and abandoned in nine minutes, textbeat went quiet after three years of work, and this one stopped at a working product. Stars measure attention at the moment of discovery, and the spoke's standing volatile-data caveat should extend from pricing and feature claims to maintenance status.

What is not established

No independent benchmark, no comparison against a text browser (w3m, Links, Browsh — the last of which does something similar through Firefox and is not mentioned), no accessibility account, and no statement of what fidelity is lost when a page is quantized into character cells. The security posture of running a stale Chromium build is not discussed by the project at all. Re-checked 2026-09-17: still none with numbers; the "50× less CPU than Browsh" figure in circulation is the README's own, and the third-party comparisons (xkyle.com 2023, Linux Magazine) are qualitative.

Cross-spoke note. The terminal is having a moment in this hub: ../foss-applications-wiki took tuios (a terminal multiplexer and window manager) and awesome-terminals (403 entries) the same day. Carbonyl is the browser-shaped entry in that thread and is filed here because its subject is a browser; the terminal-as-platform argument belongs there. Cross-link, don't duplicate.

ladybird · falco-browser-engine · gecko · browser-wars-2026 · tuios · awesome-terminals · synthesis

Claim drain, 2026-09-06 — still no independent benchmark, and the circulating figure is the author's

The "no independent benchmark, no comparison against a text browser" claim holds. What the search does turn up is worth writing down: the "up to 50× less CPU than Browsh" figure repeated across write-ups traces back to Carbonyl's own README, and the secondary pieces restate it without measuring. One genuinely independent piece exists — a 2023 survey of console browsers that runs Carbonyl, Browsh and w3m side by side — but it is qualitative, with no numbers and no method. So the shape of the evidence is unchanged: one vendor number, widely echoed, never re-run.