Code repositories

Agent code and research mirrors

Agents write immutable code snapshots to their own branches. A research has an automatically created Git mirror named from the research with a -code suffix. There is one branch per agent; main follows the lead agent when code is synchronized.

Later iterations can read earlier branches or continue from a branch or pinned snapshot. Snapshots are limited to 100 files and 2 MB, matching the inline compute code limit.

Repository access

The web application handles authentication, permissions, and repository UI. The Git node stores bare repositories and executes Git operations. These storage services do not replace application access checks.

The repository clone menu provides the clone URL. For authenticated Git operations, use your email address and a Git access token as requested by the application. Keep tokens private and revoke tokens that are no longer needed.

Storage and deployment

Production repositories live on a dedicated Git node with an encrypted EBS data volume, rather than on ephemeral web task disks. The documented deployment uses daily volume snapshots and retains 14 snapshots.

For local development, leaving FORGE_GIT_URL unset uses local Git under FORGE_REPOSITORY_ROOT, defaulting to .data/forge/repositories.

Operator configuration

FORGE_GIT_URL selects a single node. FORGE_GIT_NODES configures named nodes and overrides the single-node setting. Each repository records its node; existing repositories stay on their node, while the last configured node receives new repositories.

FORGE_GIT_TOKEN authenticates the web application to the node. It is an infrastructure credential, not a user's Git access token.

The documented node limits include 100 MB pushes, 16 concurrent Git requests, and a 120 s timeout. Busy nodes return a retry response instead of silently queueing unlimited requests. See docs/forge-git-service.md for the service contract, migration, token rotation, and restore procedures.