brainless: the npm package is private and the registry is the product

Nothing is published to npm

The manifest is explicit about not being a package. The name is `brainless`, the version is `0.1.0`, and `private` is set to true. There is no `exports` map, no `bin` and no publish configuration, because there is nothing to publish.

What consumers get instead is registry JSON. The recommended path registers a namespace and then adds components by name:

bunx shadcn@latest registry add @brainless=https://brainless.swerdlow.dev/r/{name}.json
bunx shadcn@latest add @brainless/claude-session
bunx shadcn@latest add @brainless/codex-session
bunx shadcn@latest add @brainless/grok-session

The pattern in the URL is a template, so one registry entry resolves every component by name. The same mapping can be written by hand into the project's `components.json`:

{
  "registries": {
    "@brainless": "https://brainless.swerdlow.dev/r/{name}.json"
  }
}

So the distribution unit is a file fetched from a website, and the package manifest in the repository exists to build the docs site and the registry rather than to be consumed.

Three install paths and not one version pin

Beyond the namespaced route there are two more, and they pull from different places.

The URL route addresses the site directly, either at its root or at a specific item path such as `/r/claude-session.json`. The GitHub route addresses the repository instead, with `theswerd/brainless/claude-session`. So the same component can be resolved from the author's hosted site or from the source repository, and the two are not guaranteed to be the same build at the same moment.

None of the four commands carries a version. There is no tag, no range, no commit, and the repository publishes no GitHub releases, so a component fetched today has no identifier that would let you ask for yesterday's. The registry build writes one file per component, `bun run registry:build` producing `public/r/*.json`, which means a rebuild of the site silently rewrites what every unpinned install will receive next.

The practical advice is to copy a component into your own tree and treat it as vendored source. That is how shadcn components are normally used, and it happens to be the only defense available here, since the alternative is re-running a command and taking whatever the site serves.

Each terminal gets a different vocabulary

The component table is not symmetric, and the asymmetry is the interesting part.

Claude is listed with header, message, thinking, tool call, diff, permission, prompt, slash menu and todo list. Codex gets header, message, working, exec, diff, permissions, prompt and slash menu. Grok gets status, header, message, thinking, thought, tool, write, turn end, prompt and slash menu, and then the row ends with the words and more.

Read across the rows and the three agents disagree on names, not just on coverage. Claude has a thinking piece and a single permission dialog, Codex has a working piece, an exec piece and permissions in the plural, and Grok has both thinking and thought as separate items plus a status line and a turn end. Only header, message, diff, prompt and slash menu are common to all three.

The blocks row is where the session-level pieces live: `claude-session`, `codex-session`, `grok-session` and `grok-session-active`, four of them, so a full session view exists per agent with a second, active variant for Grok only. If you are planning a page that shows the same interaction across agents, the shared five are the only ones you can assume, and the open-ended Grok row means its inventory is the one most likely to change without notice.

Fidelity is regenerated by running the three CLIs

The claim on the front page is that the components are built against real terminal captures rather than against a description, and the repository backs that with tooling rather than with prose.

registry/brainless/   # source components (claude / codex / grok / blocks / ui)
public/r/             # built registry JSON for shadcn add
references/captures/  # ANSI / HTML / text frames from real CLIs
tools/capture/        # tmux capture harness
app/                  # docs site (Next.js)
docs/screenshots/     # README screenshots

The harness under `tools/capture/` drives agents in tmux, dumps frames in three formats, ANSI, HTML and text, and lands them in `references/captures/` for side-by-side review. So the source of truth for a visual detail is a committed capture of a real CLI, which has two consequences. Regenerating fidelity means running the agents, not running a test, and any change those CLIs make to their own output, a new spinner, a reworded permission prompt, a different wrap width, becomes drift between the component and the tool it imitates.

The three output formats also explain a dependency choice further down: a diff view needs syntax highlighting, and `shiki` is in the dependency list.

One build script runs two builds, and dev runs neither registry pass

The scripts treat the docs site and the registry as two outputs of one repository.

bun install
bun run registry:build   # writes public/r/*.json
bun run dev

`registry:build` is `shadcn build`, `dev` is `next dev`, and the production `build` is `shadcn build && next build`, which the page describes as running the registry build and then Next.js. The output directories match: registry JSON lands in `public/r/`, the docs site is `app/`.

The gap between them is dev mode. `bun run dev` starts Next.js only, so the registry JSON is whatever the last build left in `public/r/`. Editing a component under `registry/brainless/` and then previewing the docs site shows the old output unless the registry build is run again, and the two commands are listed as separate steps rather than chained.

The project config tells the same story twice over. Both `components.json` and `registry.json` sit at the repository root, which is shadcn's consumer-side configuration next to the registry's own definition, so the repository is set up to both consume a registry and publish one.

Accessibility and terminal fidelity are two different targets

The front page calls these accessible React components, and separately says they are built for fidelity against real terminal captures. Those two goals rarely agree, and the dependency set shows which parts of the work are being done.

The component primitives are a real component stack: `radix-ui` for the accessible primitives, `cmdk` for the command menu that the slash menu pieces need, `class-variance-authority` and `tailwind-merge` for styling, `clsx` for class composition, `next-themes` for the light and dark variants the page shows side by side, and `tw-animate-css` for motion. `lucide-react` supplies icons and `shiki` handles the coloured output that a diff or an exec view depends on.

What is not visible on the page is how any of it is verified. There is no test script in the manifest, the only quality commands are `eslint` and the lint script, and no test directory appears in the tree. A terminal capture is a pixel-and-character reference, which tells you what to draw and nothing about whether the drawn thing is reachable by keyboard, announced, or focus-trapped.

So for a component set that ends up in a product UI, the accessibility claim is a dependency choice rather than a demonstrated property, and the captures are the only artifact that was actually reviewed.

Two agent instruction files and a lockfile for Bun

The tree is small and mostly documentation, which tells you what the project considers part of itself.

There is `AGENTS.md` and `CLAUDE.md` at the root, so instructions for coding agents ship with the components. There is `bun.lock` rather than a package lock, matching the `bunx` and `bun run` commands used for install and development, and the `components/` and `lib/` directories sit next to `registry/` for the docs site's own UI. `eslint.config.mjs`, `postcss.config.mjs`, `next.config.ts` and `tsconfig.json` are the conventional Next.js configuration, and `LICENSE` is MIT.

Version pinning is uneven in a way worth knowing if you fork this. `next`, `react` and `react-dom` are pinned to exact versions, with `eslint-config-next` pinned to the same Next version, while the rest of the list uses caret ranges. Two packages, `sharp` and `unrs-resolver`, appear in both `ignoreScripts` and `trustedDependencies`, so they are the two allowed to run install scripts in this project.

None of that travels to a consumer. Someone installing `@brainless/claude-session` gets the component's own dependency list, which is a separate question from what this repository needs to build a docs site.

Editorial conclusion

brainless is worth a look if you need to show a coding agent terminal in a docs page, a demo or a marketing page and would rather not ship a screenshot or an iframe. The fidelity claim is taken seriously, with a capture harness that runs the real CLIs and a reference directory of the frames, and the components are copy-pasteable in the shadcn sense, so they land in your project as source you own. Four things to check. Nothing pins a version, so the site and the GitHub source can drift and you have no tag to fall back on, since the repository publishes no releases. The three agents do not get the same component set, so check the table for the specific piece you need before designing around it. The npm package is private, which means there is no dependency to add and no upgrade path except re-running the install command. And the security surface is the components themselves, since the slash menu, the dialogs and the permission prompts are your code after install.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. theswerd/brainless on GitHub