> ## Documentation Index > Fetch the complete documentation index at: https://test-8ad8522e-feat-api-review-auto-fix.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Apps > Apps is where you manage authorized external applications in AI SRE. Each application appears as a card — today GitHub and GitLab. Once authorized, AI SRE can work directly inside your code repositories: read code, investigate changes / commits / PRs (or MRs), trace a PR / MR, and (when you ask) fix a bug, open a PR / MR, or file an issue. Its main job is to let the cloud sandbox reach your repositories safely. **Private beta**: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the [AI SRE private beta application form](https://c9xudyniiq.feishu.cn/share/base/form/shrcn0ngCfdoygiaHnAT80BfZiH); after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta. ## Overview *** **Apps** is where you manage **authorized external applications**. Each external application appears as a **card** — you authorize it, manage its installations, and enable / disable or revoke it right from its card. Apps today has two applications — **GitHub** and **GitLab** — covering the most common code-hosting platforms. Once you authorize one, AI SRE can **work directly inside your code repositories** during a session: understand and explore code, investigate recent changes / commits / PRs (MRs on GitLab), trace a PR / MR from a change ticket, answer questions about a codebase, and — when you ask — fix a bug, open a PR / MR, or file an issue. It all runs through native `gh` / `glab` / `git`, like an engineer working in a terminal. ## Main Scenario: Letting the Cloud Sandbox Reach Your Repositories *** AI SRE sessions run in a **Flashduty cloud sandbox** by default. The sandbox is a clean, isolated, ephemeral environment that **carries none of your git credentials** — which is exactly what an App solves. Once you authorize the GitHub App or the GitLab App, the agent inside the sandbox can clone your repositories, read diffs, and open PRs / MRs, **without you handing it any password or token**; its access is limited to the repositories you granted, with only the least privilege needed to do the work. **This is what both Apps are mainly for.** **BYOC (self-hosted Runner) generally doesn't need it.** A Runner runs on your own machine, which usually **already has `gh` / `glab` / `git` credentials configured** (you work with repositories on it every day). In that case the agent just uses the host's own credentials — **no App authorization needed**. (If the host happens to have no credentials configured, authorizing the App lets BYOC sessions use it too.) For the differences between environments, see [Environments (BYOC)](/en/ai-sre/environments). ## Where to Find It *** Go to **Plugins → Apps**. Apps is the **first and default** tab in the Plugins area — opening Plugins lands you here. Viewing the Apps tab requires the appropriate permission; without it, the tab is hidden. Authorizing, disconnecting / revoking, and enabling / disabling each require their own action permission — when you lack one, the corresponding button is shown disabled. ## The GitHub App *** The following walks through **GitHub** first — authorization, installation management, and adjusting repository access; **GitLab** follows in the next section. ### Connecting a GitHub Organization Start the authorization from the GitHub card. The whole install completes in a popup through GitHub's official install page, and the list refreshes automatically after the callback. Click **Authorize** on the GitHub card (if the App already has an installation, the button reads **More repositories**, with a + icon). The frontend opens a popup that loads GitHub's official install page. Choose the **organization** (or personal account) to install into, and grant a repository scope — **All repositories** or **Only select repositories**. The set of granted repositories determines which repositories AI SRE can access afterward. After you confirm on GitHub, the popup closes automatically, the Apps page shows **Authorized** and refreshes the installation list, and the new organization appears. If you are not the owner of the organization, GitHub routes the request to the organization owner through its request-to-install approval flow; the installation activates only after approval. Which organization to install into and which repositories to grant are decided entirely on GitHub's install page — Flashduty does not select on your behalf. ### Managing Installations Each authorized organization adds one installation row under the GitHub card. Each row shows: | Element | Description | | ----------------- | --------------------------------------------------------------------- | | Organization name | The GitHub organization / account login the installation lives on | | Status dot | A colored dot plus a label: **Connected**, **Suspended**, **Revoked** | | Repository count | The number of repositories currently granted to this installation | The toggle in the top-right of the card switches between Enabled and Disabled. **Disable = suspend**: while suspended, the agent can no longer reach those repositories — but the **GitHub installation itself is kept**, so you can re-enable instantly with one click, without going through the GitHub authorization again. An App counts as "enabled" as long as it has at least one **Connected** installation. Click **Revoke** on a row; after you confirm, the installation is set to **Revoked** and AI SRE can no longer access that organization's repositories. A revoked installation is hidden from the card; re-authorizing the same organization restores it. **Suspend** vs. **Revoke**: suspend turns it off temporarily, keeps the GitHub installation, and resumes with one click; revoke disconnects this authorization and requires going through the GitHub authorization again to use it. ### Adding or Adjusting Repository Access The organization is already connected, but you want AI SRE to reach more of its repositories — you don't need to revoke and reconnect. In **Plugins → Apps**, click **More repositories** again for that organization (or open the App's **Configure** page on GitHub directly). GitHub shows the **Repository access** screen; select the additional repositories and save, and AI SRE **re-syncs** the granted repository list automatically — the new repositories become available without re-creating the connection. **Fallback**: if a newly added repository still reports "cannot access / 404 / 403" in a session, open the App's page on GitHub (e.g. `github.com/apps/flashduty`) → **Configure** → select the organization → scroll to the **Danger zone** → **Uninstall**. Then return to **Plugins → Apps** in Flashduty and authorize the organization again, granting **all** the repositories you need in one pass. ## The GitLab App *** The **GitLab** App connects a GitLab instance — **GitLab.com**, **JihuLab** (GitLab's China distribution, SaaS at jihulab.com or a private deployment), or any other **self-managed** instance of your own. The connection method is **exactly the same for all of them**: register an OAuth application on that instance first, then authorize. Once authorized, AI SRE can read code and investigate changes / MRs, and — when you ask — file an issue or open an MR, in the repositories you authorized. Just like GitHub, **you never paste a personal token**: once Flashduty gets an OAuth grant, it provisions a dedicated bot identity for your account to do the actual work. ### Connecting a GitLab Instance Click **Connect** on the GitLab card and pick one of three options: * **GitLab.com** — the address is fixed to `https://gitlab.com`; nothing to fill in. * **JihuLab** — the address is fixed to `https://jihulab.com`; nothing to fill in. * **Self-managed** — enter the instance's root address: the part of the URL **before** the group / project path, for example `https://gitlab.example.com`. If the instance is deployed under a subpath, include it, for example `https://example.com/gitlab`. Network requests for connecting and re-authorizing GitLab are issued from the environment selected here. Public instances such as GitLab.com and JihuLab can use the default cloud environment. For a self-managed instance reachable only from a private network, choose the BYOC Runner that can reach it. The system does not automatically switch environments when a Runner is offline or unreachable; choose an available environment and start the connection or authorization again. The connect wizard shows a **copyable Redirect URI**. Take it to the GitLab instance you entered and create an OAuth application: a group **Owner** does this under **Group Settings → Applications**; on **GitLab.com**, if you're not the Owner of any group, a user-owned application under **User Settings → Applications** also works; an instance admin can also register one under **Admin Area → Applications**. Fill in the Redirect URI the wizard gave you, check **Confidential**, and check only the **api** scope. GitLab then issues an **Application ID** and a **Secret** — paste both back into the wizard. This step is the same for **every** GitLab instance — GitLab.com, JihuLab (jihulab.com SaaS or a private deployment), or any other self-managed instance: only the address changes, registering the OAuth application and pasting the Application ID / Secret works identically everywhere. This step shows which instance and which OAuth application it's about to authorize with; if you want to use a different application, click **Change OAuth application** to go back and register a different one. Once you confirm, the wizard opens a popup that loads GitLab's official authorization page; sign in with your GitLab account and confirm. The popup closes automatically once authorization completes, and the wizard advances to the next step. AI SRE shows a repository picker listing the **groups where you have the Owner role** and the **projects where you have the Maintainer role**. Select the groups / projects you want AI SRE to access and save — selecting a group covers all of its projects, including ones created later. An account can connect **only one** GitLab instance at a time (GitLab.com or one self-managed instance). To switch to a different instance, disconnect the current one first. ### Bot Identity and Permissions After you save the repository selection, Flashduty provisions a dedicated bot for the account inside those groups / projects (a service account where the instance supports it, falling back to a group- or project-level access token otherwise) for AI SRE sessions to use. Either way, the bot's permissions are capped at **Developer** level — the same minimum access you'd grant it in GitLab yourself. Tokens are **rotated automatically** before they expire; there's nothing for you to manage. If the instance doesn't support service accounts, the bot falls back to a group- or project-level token — and a token like that can only ever bind to a single group or project, so the repository picker limits you to selecting at most **one** group or project. If you select multiple groups / projects while in multi-select mode and save, Flashduty shows "This GitLab instance doesn't support service accounts; select only one group or project and retry," and switches the picker to **single-select mode**: checking a new group or project after that automatically clears any other selection, so you need to leave just one group or project checked before saving again. **One restriction on GitLab.com**: GitLab's own policy limits group- and project-level access tokens to **paid (non-free, non-trial) namespaces**. Connecting GitLab.com itself is unaffected, but if the group / project you authorize lives in a free or trial namespace, bot provisioning fails and the UI shows GitLab's own explanation ("provisioning\_denied"). Upgrade that namespace to a paid plan and re-authorize to resolve it. ### Managing a Connected Instance The GitLab card shows the connected instance's address and status. Reopens the repository picker so you can add newly needed groups / projects or remove ones you no longer need — AI SRE's access updates as soon as you save. Disconnects this instance. Flashduty makes a best effort to clean up the bot identity provisioned for the account and any tokens under it; if a cleanup step doesn't succeed, the UI surfaces a warning. All access to the instance stops immediately after disconnecting, and reconnecting requires going through OAuth authorization again. ## How AI SRE Works Inside a Repository *** After authorization, you need no extra configuration. When you ask AI SRE to work on a task in a repository during a session, it works like an engineer joining the project — understand first, then change, then verify. This behavior is governed by the built-in `github` Skill and `gitlab` Skill respectively. **Typical actions** * **Enter the repository**: clone it into its own workspace and read the repo's own conventions first (`CLAUDE.md`, `AGENTS.md`, `README`, `CONTRIBUTING`). * **Investigate changes / PRs / MRs**: use `git log`, plus `gh pr list` / `gh pr view` / `gh pr diff` / `gh search prs` on GitHub, or the equivalent `glab mr list` / `glab mr view` / `glab mr diff` on GitLab, to trace a PR / MR named in an incident or change ticket, see what a release shipped, or read a diff before deciding anything. * **Change and propose**: create a branch, make a minimal diff, open a reviewable PR / MR with `gh pr create` or `glab mr create`, or file an issue with `gh issue create` / `glab issue create`, and report the link back to you. **Hard guardrails** — the agent never crosses these: * **Never force-push** (`git push --force`), and **never push the default branch directly** — always a branch + PR / MR. * **One logical change per PR / MR**, kept reviewable; if a change balloons beyond a focused diff, it stops and hands the analysis back to you. * Never delete branches, close others' issues / PRs / MRs, or change repository settings; never commit secrets, credentials, or build artifacts. If the agent reports it cannot access a repository in a cloud session, it usually means the account has not authorized the relevant App (GitHub or GitLab), or the target repository / group was not granted — just authorize and grant it under **Plugins → Apps**. The agent does **not** ask you for any token. ## Permissions & Scope *** **Authorize** and **revoke / disconnect** are **account-level** operations for both the GitHub App and the GitLab App. **The account is the only security boundary**; the team here is just an ownership / audit tag: any account member with the corresponding permission can authorize, revoke / disconnect, or enable / disable the whole App; when a session needs a repository, it obtains access from the account's currently active installation. Members of an account share one authorization — consistent with AI SRE's "usage = account-level, ownership = team tag" model for other resources. The two Apps' scope models differ slightly: the **GitHub App** lets the same account install multiple organizations, each enabled / revoked independently; the **GitLab App** lets an account connect **only one** GitLab instance **at a time** — switching to a different instance requires disconnecting the current one first. ## Related Pages *** Connect external tools and data sources via the Model Context Protocol. Watch the agent clone a repo, read a diff, and open a PR / MR during a session. BYOC sessions use the runner host's own credentials and generally don't need the GitHub / GitLab App. The built-in github / gitlab Skill governs how the agent works inside a repository.