Forges

Your fix-login agent has pushed a branch and opened a pull request, and the panel does not know. A forge is where your code is hosted, such as GitHub or GitLab, and komrad connects to it for two reasons. It wants to show you, beside each agent, the pull request that agent’s branch has open. And agents need to push and open pull requests without you doing it for them.

Connecting a forge

You connect a forge once, by handing komrad a token. Komrad checks it with the forge straight away and refuses one that is wrong. Give the token access to the pull requests of the repositories your agents work in. GitHub and GitLab are both supported, including self-hosted. komrad forge and komrad doctor show what is connected and whether it still works.

What komrad reads

While an agent is live, komrad watches the pull requests in its repository. It notices when one is opened from the agent’s branch, when checks pass or fail, when it is approved, and when it is merged. That shows up as a symbol on the agent’s row.

Komrad asks the forge only what changed since it last looked, and backs off when the forge says it is being asked too often.

Where the token lives

The database holds only which forge and which account. The token itself sits in a file only your user can read, and never shows up in logs. This is the same arrangement as the GitHub CLI or your SSH keys.

How agents push

Agents never hold a credential of their own. When an agent’s git needs to authenticate, komrad hands it a short-lived token. No token is ever typed into a pane, so none can leak into a transcript.

On your laptop, agents use whatever git and GitHub logins you already have. On our remote engine, komrad uses a GitHub App, which makes tokens that expire after an hour. Administering the engine sets that up.

Everything so far has run on your laptop, which sleeps. Running komrad remotely moves the agents somewhere that does not.