Composer Plugin Blocked - "allow-plugins" Not Configured in CI
Composer 2.2+ refuses to run a third-party plugin unless it is explicitly listed under config.allow-plugins. In non-interactive CI it cannot prompt, so a needed plugin (e.g. an installer, a code-quality hook) is silently skipped or the command aborts.
What this error means
A package’s install behaviour is wrong, or Composer prints that a plugin is blocked because it is not enabled in allow-plugins. Locally you answered the interactive prompt once; CI never gets that chance.
composer/package-versions-deprecated contains a Composer plugin which is
currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "composer/package-versions-deprecated" to execute code ... [y/n] ?
# in CI (non-interactive) this resolves to "no" → plugin does not runCommon causes
The plugin is not in allow-plugins
Composer 2.2 made plugin execution opt-in. A plugin that is not allowlisted is blocked, and in CI the default non-interactive answer is "no".
allow-plugins exists but omits this one
A partial allowlist that misses the specific plugin still blocks it, even though other plugins run.
How to fix it
Allowlist the trusted plugin
Add the exact package name under config.allow-plugins so it runs in CI without a prompt.
{
"config": {
"allow-plugins": {
"composer/package-versions-deprecated": true,
"dealerdirect/phpcodesniffer-composer-installer": true
}
}
}Allowlist via the CLI
Equivalent change without hand-editing JSON.
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer trueAvoid the blanket allow
- List only the specific plugins you trust, with
true. - Do not set
"allow-plugins": true(allows everything) except as a temporary measure. - Commit the change so CI and local stay consistent.
How to prevent it
- Maintain an explicit
allow-pluginsmap of trusted plugins. - Review new plugins before allowlisting them.
- Keep
composer.jsonallow-plugins committed so CI is non-interactive.