> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/autofix-and-remediation/faq/assigning-default-reviewers-for-autofix-prs.md).

# Assigning Default Reviewers for AutoFix PRs

Aikido doesn't currently support configuring default reviewers for AutoFix pull requests. AutoFix opens the PR in your SCM, but it doesn't assign reviewers from an Aikido setting.

The practical path today is to enforce reviewers on the repository itself with **CODEOWNERS** and **required reviews**.

## Workaround for GitHub

Use GitHub's native CODEOWNERS support and branch protection so the right people are requested (and required) whenever AutoFix changes files they own.

{% stepper %}
{% step %}

### Add a CODEOWNERS file

Create a `CODEOWNERS` file in `.github/`, the repository root, or `docs/`. Map the paths AutoFix typically changes (for example lockfiles and package manifests) to the users or teams that should review those PRs:

```
# Dependency files commonly changed by AutoFix
package.json @your-org/security-team
package-lock.json @your-org/security-team
yarn.lock @your-org/security-team
pnpm-lock.yaml @your-org/security-team
requirements.txt @your-org/security-team
poetry.lock @your-org/security-team
Cargo.lock @your-org/security-team
go.sum @your-org/security-team
```

Adjust the paths and owners to match your repo layout. See [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) for syntax details.
{% endstep %}

{% step %}

### Require review from code owners

In your repository's branch protection rules (or rulesets) for the target branch:

1. Require a pull request before merging
2. Enable **Require review from Code Owners**

With this enabled, GitHub requests reviews from the matching CODEOWNERS and blocks merges until those reviews are satisfied. AutoFix PRs follow the same rules as any other PR.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
GitHub can also automatically request reviews from CODEOWNERS when a PR touches owned files, even before you require code owner reviews for merging. Required code owner reviews is what makes approval mandatory.
{% endhint %}

## GitLab

On GitLab, Aikido AutoFix adds CODEOWNERS as reviewers on merge requests when there are fewer than 10 CODEOWNERS for the changed files. You can turn that off with `disable_codeowners_as_reviewers` in your repo's `.aikido` file. See [Disabling CODEOWNERS as reviewers](/autofix-and-remediation/configure/autofix-pr-configuration.md#disabling-codeowners-as-reviewers).

To require those reviews before merge, configure approval rules or CODEOWNER approvals in GitLab itself.

## BitBucket

AutoFix adds CODEOWNERS as reviewers on BitBucket based on the `.bitbucket/CODEOWNERS` file when there are fewer than 10 CODEOWNERS for the changed files.

This requires a Workspace Access Token with `account:read` permissions.

<figure><img src="https://3149773201-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FyKbzcQGrx7UtrG0nPZZ7%2Fuploads%2FGND7l9NRUFA4WKh21I3J%2Fimage.png?alt=media&amp;token=fbb6a8a4-99ae-46e2-b8c1-71d74d0edb45" alt=""><figcaption></figcaption></figure>

Supported owner identifiers include email, team and username. Workspace groups are currently not supported, BitBucket advises to use teams instead.

You can turn this off with `disable_codeowners_as_reviewers` in your repo's `.aikido` file. See [Disabling CODEOWNERS as reviewers](/autofix-and-remediation/configure/autofix-pr-configuration.md#disabling-codeowners-as-reviewers).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.aikido.dev/autofix-and-remediation/faq/assigning-default-reviewers-for-autofix-prs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.