Engineering

Code Repositories

Add any git repository to your company and grant the AI employees you choose access to work on it. Each granted employee gets a real checkout in its workspace — read, branch, commit, and push, all with ordinary git.

What this is

A Code Repository is a provider-agnostic git repo the company registers under the Code section. Point it at GitHub, GitLab, Bitbucket, or a self-hosted server over HTTPS or SSH. Unlike a read-only API integration, this gives employees an editable working tree: the runner clones each granted repo into code-repos/<slug>/ inside the employee's workspace before every chat and routine run, with credentials and the committer identity already wired up.

Adding a repository

Open Code from the section menu and click Add repository.
Give it a name and paste the clone URL — https://github.com/acme/web.git or git@github.com:acme/web.git.
Pick an authentication mode and supply credentials (below). Set the default branch and an optional committer identity.
Open the repository and click Test connection to confirm Genosyn can reach it.

The Genosyn server needs git installed.

Repositories are cloned and fetched by shelling out to git on the Genosyn server, and SSH remotes also need an ssh client. The official Docker image bundles both, so there is nothing to install. On a bare-host install, make sure git (and openssh-client, for SSH auth) is on the server's PATH — otherwise Test connection reports that git is not installed on the server.

Authentication

Credentials are encrypted at rest with the same AES-256-GCM key that protects model API keys. They are never shown back to you in plaintext — the UI only reports whether a credential is stored.

None. Public repository. Clones work; pushing is rejected by the remote.
HTTPS token / password. A username plus a personal access token (with repo read/write scope). The token is handed to git at run time through an environment variable and never lands on disk. Username tips: x-access-token for GitHub, oauth2 for GitLab, your account name for Bitbucket.
SSH private key. Paste a private key whose public half is registered as a deploy key on your host. The key is written into the employee's gitignored workspace only while a checkout exists, and pinned via core.sshCommand with host keys accepted on first contact.

Granting access

On a repository's page, the Employee access panel lists who can work on it. Add an employee and choose a level:

Read & push. Full access — the employee may commit and git push. This is the default, since the point of adding a repo is usually to let an employee work on it.
Read only. The repo is cloned and kept fetched; the employee can read, branch, and commit locally, but the push URL is disabled so an accidental push fails fast.

How employees use it

Granted employees are told, in their prompt, which repositories are checked out, where, and whether they may push. They work with ordinary git — no special tooling. The built-in genosyn MCP server also exposes a list_code_repositories tool so an employee can enumerate its repos and their local paths at any time.

bash

cd code-repos/acme-web
git checkout -b fix/typo
# …edit files…
git commit -am "Fix typo in README"
git push -u origin fix/typo

Existing checkouts are only git fetched between runs, never hard-reset — so a branch an employee pushed in one run is still there the next time it starts.

Code Repositories vs. the GitHub integration

The GitHub integration is the right tool when you want an employee calling the GitHub API (issues, PRs, reviews) against repos on a connected GitHub account. Code Repositories are for the editor-shaped workflow — a working tree to commit and push to — and work against any git host, not just GitHub. You can use both.