Connect a repository

Overview

Ottili Coder works inside your existing Git repository* – it does not keep a second copy of your code and it preserves your history. Before Coder can run a task, you connect the repository once to your Coder runtime* (project). After that, Coder accesses the code through the repository's configured remote* – there is no separate GitHub or GitLab connector to set up.

Ottili Coder is publicly available as Public Beta (BETA)*. Connecting a repository is part of that release and is marked available (AVAILABLE)*; cloud runs (where your repository is sent to a managed workspace in Ottili Cloud*) are in beta (BETA)*, and direct deployment is planned (PLANNED)*. How Ottili ONE publicly labels maturity is described in [Understand feature-status labels](/docs/understand-feature-status-labels); the beta model is explained in [Public and private beta – the Ottili ONE model](/docs/product-lifecycle-and-feature-status).

What you need

• A Git repository* with a configured remote (HTTPS or SSH).
• Access to the Ottili ONE Unified API* (locally on port 8100 or your deployed instance) and an API token for your workspace.
• Optionally the Ottili Coder CLI* (see [Install the CLI](/docs/cli-installation)).

Every connection is company-scoped*: the repository resolves to exactly one company (company_id) and is protected by Ottili Core* tenant isolation. A repository you connect is not visible to other companies.

Connect a repository

You connect a repository through the Coder CLI or through the Coder surface (dashboard/desktop). Either way the connection lands on the same canonical Coder REST address POST /api/v1/coder/repositories/connect on the Unified API.

Via the CLI

The repositories group of the coder commands talks to the Unified API:

ottili coder repositories connect "<source>" \
  --remote-url https://github.com/organisation/repo.git \
  --branch main

As the <source> (raw) you can provide:

• a local path* to an already checked-out clone,
• a GitHub/GitLab URL* (or a URL of a self-hosted remote),
• an archive file* (ZIP),
• or ottili:// for an Ottili-managed source type.

Useful options:

• --local-path – local checkout path for deep analysis.
• --remote-url – explicit remote URL (GitHub, GitLab, Bitbucket, self-hosted).
• --branch – default branch Coder works on.
• --project-id – associate with a Coder project.
• --mission-id – associate with a [mission](/docs/coder-missions) (mission → plan flow).
• --idempotency-key – key for safe retries (idempotent).

After connecting, Coder replies with the detected source_type, a repository id, and a status (for example connected).

Via dashboard or desktop

In the Coder surface (dashboard or desktop) you connect a repository and provide the same source (local path, remote URL, archive, or ottili://). The surface sends the same request to the Unified API; no second, orphaned repository is created.

Supported repository providers

Coder uses the configured remote* of your repository. Supported providers include:

• GitHub*
• GitLab*
• Bitbucket*
• self-hosted* remotes (over HTTPS or SSH URL)

Because Coder uses the repository's remote, you need no platform-specific connector – you connect your repository the same way you configured it for your existing tools.

Authentication

Coder accesses the code through the credentials your remote is already configured with* (for example an OAuth app, a personal access token, or an SSH key you set up for GitHub/GitLab/Bitbucket). There is no separate Coder login for Git: Coder uses the same authentication as your local git. You control the Unified API credentials (your workspace token) through environment variables – see [Install the CLI](/docs/cli-installation).

All access is company-scoped* and logged with Ottili Core* tenant isolation.

Manage connected repositories

Once connected, you can manage the connection through the same CLI group:

• ottili coder repositories list – list the company's connected repositories.
• ottili coder repositories show <id> – show a repository with its full context.
• ottili coder repositories context <id> – show only the analysed repository context.
• ottili coder repositories refresh <id> – recompute and merge the repository context.
• ottili coder repositories disconnect <id> – disconnect a repository (idempotent, safe to retry).

Local, cloud and hybrid

Once a repository is connected, the Git integration behaves consistently across the Coder modes:

• Local run* – Coder operates directly on your working repository.
• Cloud run* – your repository and task context are sent to a managed workspace in Ottili Cloud*; the branch and pull request return to the same repository and remote* (beta).
• Hybrid run* – tasks are distributed locally and in the cloud by context; the Git results converge in the same repository.

Details are in [Git and GitHub integration](/docs/coder-git) and the [Coder modes](/docs/coder-modes).

Permissions and approvals

Risky Git steps (for example force-push, changes to protected branches, or overwriting tags) follow the same permission and approval model as other Coder actions. Which tools a run may use and where an approval is required is covered in [Tools and permissions](/docs/coder-security). The actual check runs through [Testing and validation loops](/docs/coder-validation) before a task is considered done.

Maturity status

Related articles

• [Ottili Coder – Overview](/docs/ottili-coder)
• [Ask Plan Build Fix Review – Coder modes](/docs/coder-modes)
• [Git and GitHub integration](/docs/coder-git)
• [Install the Ottili Coder CLI](/docs/cli-installation)
• [Missions](/docs/coder-missions)
• [Tools and permissions](/docs/coder-security)
• [Understand feature-status labels](/docs/understand-feature-status-labels)
• [Public and private beta – the Ottili ONE model](/docs/product-lifecycle-and-feature-status)