atgc: atproto git client

Lately I've been working on a new multiplayer project*¹. 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:

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 requested*²:

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:

1. Ensure you're logged into a DID
2. Do a traditional git clone
3. 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
4. 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.