Symptoms covered
- An old OAuth pipeline still appears in the Trigger Pipeline dropdown after you removed its trigger from Project setup.
- Two pipelines run for every push or tag, about one second apart.
- Every CI job posts two status checks to GitHub, one from
circleci-app[bot]and one from the committer's GitHub user. PRs showmergeStateStatus: BLOCKEDeven when every check is green.
All three trace back to how OAuth pipelines coexist with GitHub App pipelines on the same project.
Why the OAuth pipeline stays around
For any project that exists in a GitHub OAuth organization, CircleCI keeps an OAuth pipeline for that project. Per the Pipeline types documentation, the OAuth pipeline:
- Is created automatically for OAuth organizations (one and only one per project).
- Cannot be deleted.
- Cannot be renamed.
- Can still be triggered via API or manually through the web app, even after its GitHub trigger is removed.
When you install the GitHub App for the same project, a second pipeline (a GitHub App pipeline) is created. Both can coexist, and the OAuth pipeline remains visible in Project setup and in the Trigger Pipeline dropdown. The OAuth pipeline by itself does not start builds or post status checks unless something is attached to it (a trigger, a webhook, or the VCS Status Updates project setting). Each symptom below is caused by one of those, and each has its own fix.
Symptom 1: Persistent OAuth pipeline in the Trigger Pipeline dropdown
You removed the OAuth trigger but the OAuth pipeline is still listed in the Trigger Pipeline dropdown. It may also still appear as a card on Project setup with no delete control.
Why this happens
The dropdown lists every pipeline on the project, and per the Pipeline types docs the OAuth pipeline cannot be deleted.
What you can do
- Confirm the OAuth pipeline has no triggers attached. In Project settings → Project setup, locate the OAuth (GitHub) card and check the Trigger on section. It should be empty.
- With no triggers, the OAuth pipeline will not start automatically. Per the Pipeline types docs, it can still be triggered manually or via API, but that requires intentional action.
Symptom 2: Two pipelines run for every push or tag
Every push or tag creates two pipeline runs within about one second of each other.
Why this happens
Two webhook deliveries are reaching CircleCI for the same event. The two most common causes (covered in the docs) are:
- A GitHub App trigger and a GitHub OAuth trigger are both configured on the same project. Per the docs, this is a known cause of duplicate builds.
- The repository has more than one CircleCI webhook in its GitHub webhooks list, so the same event is delivered to CircleCI twice. Covered in the Troubleshooting duplicate builds support article.
What you can do
- Delete the OAuth trigger from Project setup. In the CircleCI web app, go to Project settings → Project setup. Find the OAuth (GitHub) card and look at the Trigger on section. Delete any triggers listed there. This is the fix the docs recommend in How do I prevent duplicate builds?
- Check GitHub repository webhooks. Go to your GitHub repository → Settings → Webhooks. If you see more than one CircleCI webhook here, remove the duplicates. The Troubleshooting duplicate builds support article covers the full walkthrough.
If duplicates persist after the steps above, open a Support ticket and include both pipeline URLs from the CircleCI web app.
Symptom 3: Duplicate PR status checks blocking merges
Every CI job posts two status checks to GitHub: one from the CircleCI App (posting as circleci-app[bot]) and one from the committer's GitHub user identity. Job names appear twice in the PR checks list, and GitHub may report mergeStateStatus: BLOCKED even when all checks are green.
Why this happens
CircleCI projects can report status to GitHub through two different paths, both documented in the Status updates overview and the Enabling GitHub Checks guide:
- VCS Status Updates (sometimes labeled "GitHub Status Updates" in older docs and parts of the UI) post per-job updates to GitHub using the committer's OAuth credentials. This is the default for OAuth-connected projects.
- The CircleCI GitHub App posts checks as
circleci-app[bot]once it is installed.
When both are active on the same project, every job completion posts to both, producing duplicate entries. GitHub evaluates the latest entry per check name when applying branch protection rules, so if the OAuth-side status posts last, branch protection rules that require a check from a specific integration ID will see the OAuth-sourced status and the rule will fail, even though the check passed.
What you can do
The Status updates overview covers this exact case: "If you use the GitHub Checks feature, you can disable status updates to avoid duplication of statuses."
- Disable VCS Status Updates in the CircleCI web app: Project settings → Advanced Settings → set VCS Status Updates to
off. The CircleCI GitHub App will continue reporting via its own integration. - Update branch protection rules if needed. If any branch protection rules in GitHub were written for the OAuth-based check names, repoint them to the GitHub App check names. This is a one-time migration.
Comments
Article is closed for comments.