atgc: atproto git client

Lately I've been working on a new multiplayer project1. Because it's an ATProto-native project, I decided to host it all on Tangled.

This project spans multiple repos, and it involves commits from both my main account (@permadeath.com) and my project-specific account. The project is also mainly agent-written on my laptop, so it requires high parallelism with git worktrees.

There are a few Tangled CLIs already, but I wanted to make something that really feels ATProto-native and that is oriented around my specific workflows. I started with the gh CLI as an inspiration and then worked with Claude to refine the CLI surface and implementation details (in Rust, make a breakthrough, no mistakes).

A few days and a hundred or so commits later, atgc is at a point where all of my agents use it to iterate on itself. I guess that means I'm happy enough to ship it:

permadeath.com/atgc

Logging in

For now, you need to install atgc via cargo from a local checkout. Once you do, login looks like this:

This opens a consent form on your PDS:

Accepting brings you to this lovely screen, and writes out an access token to a config directory:

At that point, `atgc auth status` will tell you which accounts you're logged in as and what scopes the currently active account has requested2:

All OAuth operations are JSON-logged to help you understand any glitches incurred by agent parallelism:

Doing stuff

Generally, you'll still use git commands to get work done on the day to day. But atgc commands help you configure git reliably and in a Tangled-friendly way.

For example, the repo clone command will:

Ensure you're logged into a DID

Do a traditional git clone

Set up the .git/config to send that DID's Tangled-style ATProto creds, so you don't accidentally send commits into your public PDS with GitHub style realname/realemail creds

Detect which private key to offer, and write it into the .git/config for pushes

Tangled also has a different PR workflow than GitHub, which isn't as "push-to-branch" oriented. So the commands attempt to implement that, in a way that agents can reasonably discover.

Limitations

There's a lot of them! Off the top of my head:

No CI implemented, I have to do releases myself.

No support for issues, spindles, labels, and other features I don't yet use.

No artifact-based install path.

Currently, atgc doesn't use any keyring or other secure storage.

Not tested on anything other than ubuntu 26.04

No integration tests covering more 'end to end' productivity workflows

Few edge cases for more complex ATProto use cases, like down PDSes, large DID record sets, etc.

Honestly I don't write that much Rust, it could all be total garbage, I wouldn't know.

Future development

Just, like, DM me about it or whatever. I'm mainly focused on my own use cases but I'll give most things a shot if they sound compelling.

More on that soon...

Mainly useful for debugging, in case atgc adds new required scopes that your old auth lacked.