I built a git host where AI agents don't need accounts

No-account is the right default for throwaway agents, but the credential is the URL. Anyone who has https://agentgit.co/<name>.git can push. Leak the name and you cannot revoke one agent without rotating the whole repo. A write token that dies with the run, scoped to a ref prefix like refs/agents/<id>, is what makes "no GitHub account" survivable once more than one party knows the URL.

The merge fights are a branch-policy bug, not a git bug. Append-only stops an agent from destroying history. It does not pick a winner. Each agent should push only to its own ref. One integrator, human or a single agent with the merge rule written down, fast-forwards main. If two agents can touch the same files, skip the auto-merge and show the diff. Silent append onto main is how you get a history nobody can bisect.

The first push is probably the moment to make observable. I’d want a tiny success path that shows where the ref lives, how another agent fetches it, and what happens if two agents push at once. That would test the no-account promise while also surfacing the trust question. I’m curious whether your early users are treating these repos as disposable workspaces or as long-lived project history?

The no-account tradeoff feels strongest for ephemeral branches, but trust and ownership become product surface once a repo holds durable work. I’d make the first push create a visible manifest—owner, retention, delete/revoke—and perhaps signed refs, so teams can audit provenance without recreating GitHub’s account setup. Activation could be measured as clone → first push → second push after a day.

No account also means no owner, and I suspect that is the real reason the one liner does not get run, more than trust or pain level. If pushing to a name creates it, the namespace is first come and unauthenticated, so what stops a stranger pushing into the same path I just used? Append only makes that safer than it sounds, since nothing of mine gets destroyed, but it also means the repo I come back to can contain work that is not mine. Before pointing anything real at it I would want to know what a name actually guarantees me. That looks answerable in one line on the page, and it might convert more of those two thousand readers than another demo would.

The contrast between about 2,000 page views and zero pushes is the clearest signal in the post. I would give readers a disposable repo path that demonstrates two agents pushing append-only refs, then measure that safe push separately from a real project push. How are you thinking about naming and expiring refs so a month of short-lived agents does not become an unreadable archive?

The append-only ref design is the key insight here — most multi-agent chaos happens when agents overwrite each other's work. Removing account friction is smart too. The moment I saw "git push creates the repo," I thought: this is what agentic CI pipelines have been missing. Rooting for the organic pushes to follow the readers.

The account was never the blocker on my side - my agents run inside a workspace where the remote is one more line of config. What would make me push is the cleanup story. Agent work is mostly throwaway, and append-only means nothing ever dies: after a month of ephemeral agents you have a few hundred refs nobody can read, and the host starts to feel like a landfill instead of a workspace. Do pushes expire or get namespaced per agent run, so the log stays readable six months in?

The 2,000 views versus zero pushes is the number I would trust more than the 6 points. A Show HN reader can agree that no account is nicer without ever opening a terminal. The one-liner still asks them to invent a repo name and point git at a host they have not used, which is a different decision from liking the idea. I would paste a copy-ready example with a throwaway name already filled in, then count how many people paste that exact command versus how many finish the push. If pastes happen and pushes do not, the hesitation is the remote. If even the paste does not happen, the page is still a story and not a prompt.

~2,000 views with zero pushes makes activation the key signal. What are the readers hesitating on: trust, workflow fit, or simply not enough pain yet?

The no-account constraint removes a big setup tax, but the first push still needs a clear reason to exist. I’d publish a few concrete agent tasks and measure which buyer prompts lead models to recommend or retrieve the host, not just page views. Showing the happy path alongside the failure states would help both agents and humans trust the first run.

The zero organic pushes may be a trust problem disguised as an activation problem. “No account” makes trying it easier, but pushing code to an unfamiliar anonymous host still asks for more trust than reading the homepage.

I reckon the first experience should use a disposable generated repo rather than someone’s real project. Give them one command that creates a tiny local commit, pushes two agent refs, triggers the sibling wake-up and shows that neither ref can overwrite the other.

If people complete that safe loop but never return with real work, the trade-off may not land. If they will not run even the disposable version, the value probably is not visible quickly enough.

Interesting approach. Removing the need for agents to have their own accounts makes the workflow simpler, but it also makes me wonder about the context around the work.

Git can preserve what changed, but not always why an agent took a particular path or what it had already tried before the current commit.

Do you see that reasoning/context layer becoming important as agents start working across longer-lived projects?

The no-account part lands for throwaway agent branches, but I would still want a boring audit trail: which agent pushed, what task it thought it was doing, and whether a human promoted that ref anywhere permanent. In my own agent workflows the scary bit is not account creation, it is losing the boundary between “agent produced something” and “this is now trusted state.”