lea · Agents at work

Git and forges

lea needs no forge account, and works with any of them.

HTTPS, by default. git clone, pull and push over HTTPS reach GitHub, GitLab, Gitea, Bitbucket or any public forge through the proxy. gh and glab are in the image; what they keep lives in lea's state, never in your home directory.
GitHub: the token stays in the proxy. Give lea a GitHub token on the host, once:
```
gh auth token | lea github login     # or: lea github login < token-file
lea github status                    # is there one (never shows it); lea github logout removes it
```
It is kept in ~/.local/share/lea/proxy/forge/github.com (mode 0600) and mounted in the proxy container only. The agents' gh (through a relay socket, /run/lea-forge/gh.sock) and git (https://github.com/ goes to http://lea-proxy:4401/) send their requests without it; the proxy's forge forwarder drops whatever credential they carry, adds the token for api.github.com, uploads.github.com and github.com, and goes on over HTTPS through the egress proxy (or the LockHTTP gate). gh sends every request through the socket, the redirects it follows included: the forwarder sends each to its own host, with the token for those three only (a job log's or an artifact's redirect to *.blob.core.windows.net goes there without it; that domain is not in lea's default allowlist: gh run view --log and gh run download need LEA_EGRESS_ALLOW="default,blob.core.windows.net"). Only lea-proxy:4401 (git) means github.com. An agent can use the token for what it allows, never read it, and only for the calls lea's gh and git workflows make: the forwarder keeps an allowlist and refuses (403) everything else. On api.github.com: reads of the user, users, repos/{owner}/{repo}/…, orgs/{org}/…, search and rate limit; writes under repos/{owner}/{repo}/ on issues, pull requests, labels, milestones, contents, git data (refs, blobs, trees, commits, tags), releases, check runs, statuses, and of Actions a run's rerun, cancel or deletion and a workflow's dispatch; GraphQL queries, and only the mutations of gh issue, gh pr and gh project (issues, pull requests and their reviews, comments, labels, assignees, project items). On uploads.github.com, a release asset; on github.com, git's protocol (and Git LFS, archives, release downloads). So no collaborator, invitation, transfer, repository or organisation setting, membership, key, webhook, Actions secret, variable or runner token, nor the ID aliases (/repositories/{id}, /organizations/{id}) of any route; a path with an empty, . or .. segment, an escaped slash or a ; is refused too. Make those on the host. A GitHub token in the agents' state (/lea/state/gh/hosts.yml, or a github.com line of git's store) is removed at each lea. Any agent can write that state, so such a token never replaces the proxy's: it is discarded with a warning (lea github login changes lea's token). Only the first lea of this version, when the proxy has no token yet, adopts the one an earlier lea left (the marker ~/.local/share/lea/proxy/forge-migrated then stops it, even after lea github logout). Prefer a fine-grained token limited to the repositories of the projects directory, without administration or workflow permissions.
Other forges. Log in from a shell in lea (lea shell, or s in the deck): glab auth login, or a token in git's credential store. Those tokens stay readable by the agents (see What an agent can read).
SSH, if you prefer. List the endpoints in ~/.config/lea/lea.conf, pin their host keys, and rerun lea init: it creates lea's own key and prints the public key to add to your forge.
```
echo 'LEA_GIT_SSH="github.com:22 gitlab.com:22"' >> ~/.config/lea/lea.conf
ssh-keyscan github.com gitlab.com >> ~/.config/lea/git_known_hosts   # compare the fingerprints
lea init
```
Each endpoint gets its own forwarder in the proxy; agents use lea's key, never yours.
Container registries. podman login (or docker login) in lea; the login is kept for the next sessions.