Brnch launches a code host that gives each coding agent its own account, acting on behalf of a sponsoring person

An agent that pushes a commit on GitHub shows up as whichever human minted the personal access token. Brnch, a new Git host that launched on Product Hunt yesterday afternoon, splits those two roles apart: every coding agent gets its own account on Brnch, and that account is always acting on behalf of a sponsoring person. Who did the work and who authorised it are two different lines in the log.

The company's own description of the rule reads: "On Brnch every agent acts for a person who sponsors it: you never get an account of your own, and what you change is recorded as you, the agent, on their behalf." The host is Git underneath, so standard clients still work, and the founder, Ilyas Esmail, is listed as the Product Hunt maker.

How an agent signs in

Brnch publishes an auth.md at brnch.io/auth.md that is written for a coding agent to read. The CLI command brnch auth login --email you@example.com --no-wait prints a link and an eight-letter code, which the agent hands back to the person in a single message. The person opens the link, signs in or creates an account with that email, types the code, and approves. Then brnch auth login --continue returns a scoped token. Access tokens last an hour and can be refreshed; a sign-in lasts at most 90 days.

brnch setup then connects the current directory to a repository, commits what is there if nothing is committed yet, and pushes it as the default branch main. It also writes a short Brnch section into the agent config files it finds on disk. Brnch names the runtimes it recognises: Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Aider, Copilot, Grok, Amp, Factory Droid, Windsurf, and Cline. After that first push, main is protected and changes reach it only through reviewed changes.

What the agent can and cannot do

The sign-in gives the agent read access to anything the sponsoring person can read, and write access only through "agent sessions" scoped to one repository at a time. A session can push branches, open changes, comment on reviews, and report evidence from checks. Brnch is explicit about what a session cannot do: approve or merge, administer the organisation, add SSH keys, or act as the person. Those stay with the human, and the CLI refuses to raise its own privileges around a policy refusal.

Every merge, Brnch says on its own home page, "lands with proof: who wrote it, who approved which revision, which independent checks ran on the exact tree that merged." The last clause is the one that matters: tests run against the merge result rather than against the submitted branch, and the result is signed.

The MCP and A2A surfaces

Brnch publishes a Model Context Protocol server at brnch.io/mcp, with 57 tools in the server card: search, fetch, repo_list, change_create, review_approve, merge_request, delegate_to_agent and the rest. Sign-in is OAuth 2.1 with PKCE and dynamic client registration. There is also a read-only A2A agent at brnch.io/a2a for other agents to call, with the same OAuth plumbing. Both are listed in a /.well-known/ai-catalog.json.

Brnch is new and unmeasured. The home page carries no customer count, no benchmark, no price. The company is pitching a design decision rather than reporting one, and a team evaluating it has to measure whether sponsored agent identity is the right primitive for its own review process. The useful move for now is to sign one Claude Code or Codex session in through the CLI, push a branch, and read the audit trail that comes out the other side.

Source

• Primary source: Brnch home page, brnch.io/auth.md, MCP server card, AI catalog, all read 6 October 2026.
• Launch: Product Hunt listing for Brnch, posted 5 October 2026 by Ilyas Esmail.