GitLab · CI/CD pipeline variables · pipelines and jobs API · Checked October 24, 2026

GitLab: "Insufficient permissions to set pipeline variables"

Pipeline variables are the variables given when a pipeline is started: in the Run pipeline form, through the pipelines or triggers API, in a pipeline schedule, with push options, or by a trigger job for another project's pipeline. Since GitLab 17.1 a project can limit who may use them, under Settings > CI/CD > Variables > Minimum role to use pipeline variables (GitLab's documentation). Below that role, a new pipeline with variables is refused. All of this is from GitLab's source (lib/gitlab/ci/pipeline/chain/build/associations.rb, app/services/ci/play_build_service.rb, app/models/project_ci_cd_setting.rb), read on October 24, 2026:

HTTP/1.1 400 Bad Request

{"message":{"base":["Insufficient permissions to set pipeline variables"]}}

The setting

• no_one_allowed: no pipeline can run with pipeline variables. On gitlab.com this is the default for new projects in new namespaces since GitLab 17.7. In the source, a new project takes the default of its top-level group.
• owner: only the Owner role. maintainer: the Maintainer or Owner role; the default on GitLab Self-Managed and GitLab Dedicated when nothing is set. developer: the Developer role and up, which is everyone who may run pipelines.
• In the source, the instance's administrators may always use them.

The setting does not touch the CI/CD variables of the project or group, or variables in .gitlab-ci.yml. Child pipelines in the same project are not restricted either.

Where it shows

• A new pipeline (POST /projects/:id/pipeline with variables): 400 as above. GitLab checks it after the branch or tag exists and before it reads .gitlab-ci.yml, so a rules message cannot come first. GitLab's own Run pipeline form hides its variables from accounts that may not use them, so it sends none.
• The triggers API: refused with the same message when the trigger token's owner may not use them. TRIGGER_PAYLOAD, which GitLab adds itself, is let through on its own.
• A manual job run with variables (POST /projects/:id/jobs/:job_id/play with job_variables_attributes): a bare {"message":"403 Forbidden"}, the same answer as when your account may not run the job at all, so the variables are not named. Without variables, the same job runs. GitLab's job page hides the variables from such accounts.
• A trigger job for another project: it fails with downstream pipeline can not be created, Insufficient permissions to set pipeline variables. Your role in the downstream project counts, not in this one, and the trigger job also passes the top-level variables unless it has inherit:variables: false (GitLab's troubleshooting page).

What to do

• Run it without variables. GitLab recommends pipeline inputs instead of pipeline variables from GitLab 17.7 on.
• Ask about the setting: a Maintainer can change it; once it is owner or no_one_allowed, only an Owner can.
• A manual job's 403: run it without variables. If it is still refused, the cause is your role or a protected branch; see why GitLab refused the job.
• A trigger job: remove its variables, add inherit:variables: false, or ask for a higher role in the downstream project.

GitLab pipelines in IntelliJ IDEA

Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists your GitLab projects' pipelines with their jobs and logs, and with Pro runs new pipelines and manual jobs with variables. Its Run Pipeline dialog fills in the variables .gitlab-ci.yml offers, as GitLab's own form does, and when GitLab refuses, it stays open with GitLab's reason. From version 1.0.17, where your role may not use pipeline variables, it starts the pipeline without the offered variables you left unchanged, as GitLab's own form does (the pipeline still gets their values from .gitlab-ci.yml); if you changed them, or gave variables to a manual job, it names the Minimum role to use pipeline variables setting. Before, it sent the offered variables anyway, so GitLab refused until you removed them all. Reading is free; retrying, cancelling and running are Pro (US$1.50 a month, with a 30-day trial).

GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.

More: GitLab pipeline or job refused (400, 403, 409, 429) · GitLab job log refused or empty (403, 404) · GitLab "insufficient_scope" · GitLab 401 "invalid_token" · GitLab 404 "Group Not Found" · GitLab pipeline plugins for IntelliJ IDEA, compared · 日本語