Brainless GitHub panels and the trust they borrow

Brainless is a small shadcn/ui registry of components styled after the coding agents people already use. Transcript panes, composer boxes, the flat grey chrome that makes a long-running task feel readable. You install the components into your own project and own the code, the way shadcn distribution normally works.

It is a component kit. No model, no runtime, no permissions. The agent behaviour is whatever you connect behind it.

Why the GitHub example is the interesting one

The pairing people reach for first is Brainless plus GitHub. You build a panel that shows a repo, a diff, a suggested change, and a button. It reads beautifully in a demo. Then somebody wires the button to a real token and the demo becomes production.

The failure we have watched happen more than once: the panel renders a summary the model produced from stale context, a reviewer skims it because the interface looks authoritative, and a branch gets changed on the strength of a paragraph nobody verified. The UI never lied. It just never said which repo, which ref, or whether the action was read-only.

Make the boundary visible in the component

If you are building a Brainless GitHub surface, put the facts in the component itself rather than in a doc someone read in onboarding:

• The exact repository and branch the panel is pointed at, rendered as text, not implied by a title
• A read or write label on every action control, decided by the token scope rather than by intent
• The raw diff behind a toggle, so the summary is checkable in one click
• A disabled state with a reason when the tool is unavailable, instead of a button that fails after the click
• The timestamp of the fetch, because stale is the common case

Scope the token before you style the button

The GitHub MCP server, or any GitHub tooling you hang behind the panel, inherits exactly the permissions of the credential you hand it. Start read-only. A fine-grained personal access token limited to one repository with contents and pull request read access will cover a review panel entirely. Add write scopes only when a specific workflow demands it, and add them on a separate token so revoking is one action.

Keep the credential out of the browser. The panel is a client component. The GitHub call belongs on a route handler where the token never reaches the page bundle.

What to do next

Take whatever agent panel you have built and hand it to somebody who did not write it. Ask them three things. Which repo can this touch? Can this button write? Where is the underlying diff? If they cannot answer from the screen in under ten seconds, the component is not finished. Fix that before you fix the styling.

If you want help putting this into practice, talk to us.