permission-syncing.mdx

title	Permission syncing
sidebarTitle	Permission syncing

import LicenseKeyRequired from '/snippets/license-key-required.mdx'

Overview

Permission syncing allows you to sync Access Permission Lists (ACLs) from a code host to Sourcebot. When configured, users signed into Sourcebot will only be able to access repositories that they have access to on the code host. Practically, this means:

• Code Search results will only include repositories that the user has access to.
• Code navigation results will only include repositories that the user has access to.
• MCP results will only include results from repositories the user has access to.
• Ask Sourcebot (and the underlying LLM) will only have access to repositories that the user has access to.
• File browsing is scoped to the repositories that the user has access to.

Permission syncing can be enabled by setting the EXPERIMENT_EE_PERMISSION_SYNC_ENABLED environment variable to true.

docker run \
    -e EXPERIMENT_EE_PERMISSION_SYNC_ENABLED=true \
    /* additional args */ \
    ghcr.io/sourcebot-dev/sourcebot:latest

Enabling permission syncing on an **existing** deployment may result in errors that look like **"User does not have an OAuth access token..."**. This is because the OAuth access token associated with the user's existing account does not have the correct scopes necessary for permission syncing. To fix, have the user re-authenticate to refresh their access token by either logging out of Sourcebot and logging in again or unlinking and re-linking their account.

Platform support

We are actively working on supporting more code hosts. If you'd like to see a specific code host supported, please reach out.

Platform	Permission syncing
GitHub (GHEC & GHEC Server)	✅
GitLab (Self-managed & Cloud)	✅
Bitbucket Cloud	🟠 Partial
Bitbucket Data Center	🟠 Partial
Gitea	🛑
Gerrit	🛑
Generic git host	🛑

Getting started

GitHub

Prerequisites:

• Configure a GitHub connection.
• Configure GitHub as an external identity provider.
• If you are using a self-hosted GitHub instance, you must also set the baseUrl property of the github identity provider in the config file to the base URL of your GitHub instance (e.g. https://github.example.com).

Permission syncing works with GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. For organization-owned repositories, users that have read-only access (or above) via the following methods will have their access synced to Sourcebot:

• Outside collaborators
• Organization members that are direct collaborators
• Organization members with access through team memberships
• Organization members with access through default organization permissions
• Organization owners.

Notes:

• A GitHub external identity provider must be configured to (1) correlate a Sourcebot user with a GitHub user, and (2) to list repositories that the user has access to for User driven syncing.
• OAuth tokens must assume the repo scope in order to use the List repositories for the authenticated user API during User driven syncing. Sourcebot will only use this token for reads.

GitLab

Prerequisites:

• Configure a GitLab connection.
• Configure GitLab as an external identity provider.
• If you are using a self-hosted GitLab instance, you must also set the baseUrl property of the gitlab identity provider in the config file to the base URL of your GitLab instance (e.g. https://gitlab.example.com).

Permission syncing works with GitLab Self-managed and GitLab Cloud. Users with Guest role or above with membership to a group or project will have their access synced to Sourcebot. Both direct and indirect membership to a group or project will be synced with Sourcebot. For more details, see the GitLab docs.

Notes:

• A GitLab external identity provider must be configured to (1) correlate a Sourcebot user with a GitLab user, and (2) to list repositories that the user has access to for User driven syncing.
• OAuth tokens require the read_api scope in order to use the List projects for the authenticated user API during User driven syncing.
• Internal GitLab projects are not enforced by permission syncing and therefore are visible to all users. Only private projects are enforced.

Bitbucket Cloud

Prerequisites:

• Configure a Bitbucket Cloud connection.
• Configure Bitbucket Cloud as an external identity provider.

Permission syncing works with Bitbucket Cloud. OAuth tokens must assume the account and repository scopes.

**Partial coverage for repo-driven syncing.** Bitbucket Cloud's [repository user permissions API](https://developer.atlassian.com/cloud/bitbucket/rest/api-group-repositories/#api-repositories-workspace-repo-slug-permissions-config-users-get) only returns users who have been **directly and explicitly** granted access to a repository. Users who have access via any of the following are **not** captured by repo-driven syncing:

• Membership in a group that is added to the repository
• Membership in the project that contains the repository
• Membership in a group that is part of a project containing the repository

These users will still gain access via user-driven syncing, which fetches all private repositories accessible to each authenticated user. However, there may be a delay between when a repository is added and when affected users gain access in Sourcebot (up to the experiment_userDrivenPermissionSyncIntervalMs interval, which defaults to 24 hours).

If your workspace relies heavily on group or project-level permissions rather than direct user grants, we recommend reducing the experiment_userDrivenPermissionSyncIntervalMs interval to limit the window of delay.

Notes:

• A Bitbucket Cloud external identity provider must be configured to (1) correlate a Sourcebot user with a Bitbucket Cloud user, and (2) to list repositories that the user has access to for User driven syncing.
• OAuth tokens require the account and repository scopes. The repository scope is required to list private repositories during User driven syncing.

Bitbucket Data Center

Prerequisites:

• Configure a Bitbucket Data Center connection.
• Configure Bitbucket Data Center as an external identity provider.

Permission syncing works with Bitbucket Data Center. OAuth tokens must assume the PUBLIC_REPOS and REPO_READ scopes.

**Partial coverage for repo-driven syncing.** Repo-driven syncing only captures users who have been **directly and explicitly** granted access to the repository. Users who have access via any of the following are **not** captured by repo-driven syncing:

• Project-level permissions (inherited by all repos in the project)
• Group membership

These users will still gain access via user-driven syncing, which fetches all repositories accessible to each authenticated user using the REPO_READ scope. However, there may be a delay between when access is granted and when affected users see the repository in Sourcebot (up to the experiment_userDrivenPermissionSyncIntervalMs interval, which defaults to 24 hours).

If your instance relies heavily on project or group-level permissions, we recommend reducing the experiment_userDrivenPermissionSyncIntervalMs interval to limit the window of delay.

Notes:

• A Bitbucket Data Center external identity provider must be configured to (1) correlate a Sourcebot user with a Bitbucket Data Center user, and (2) to list repositories that the user has access to for User driven syncing.
• The connection token must have Repository Read permissions so Sourcebot can read repository-level user permissions for Repo driven syncing.
• OAuth tokens require the REPO_READ scope to list accessible repositories during User driven syncing.

How it works

Permission syncing works by periodically syncing ACLs from the code host(s) to Sourcebot to build an internal mapping between Users and Repositories. This mapping is hydrated in two directions:

• User driven : fetches the list of all repositories that a given user has access to.
• Repo driven : fetches the list of all users that have access to a given repository.

User driven and repo driven syncing occurs every 24 hours by default. These intervals can be configured using the following settings in the config file:

Setting	Type	Default	Minimum
experiment_repoDrivenPermissionSyncIntervalMs	number	24 hours	1
experiment_userDrivenPermissionSyncIntervalMs	number	24 hours	1

Manually refreshing permissions

If a user's permissions have changed and they need access updated immediately (without waiting for the next scheduled sync), they can trigger a manual refresh from the Linked Accounts page:

1. Navigate to Settings → Linked Accounts.
2. Click the Connected button next to the relevant code host account.
3. Select Refresh Permissions from the dropdown.

The button will show a spinner while the sync is in progress and display a confirmation once it completes.