Skip to content
Latchkey

semantic-release "ENOGHTOKEN" no GH_TOKEN or GITHUB_TOKEN in CI

The @semantic-release/github plugin needs a GitHub token to create the release and comment on issues, and it looks for GH_TOKEN or GITHUB_TOKEN in the environment. Neither was set for the step, so it aborts during "Verify Conditions".

What this error means

The run stops with "ENOGHTOKEN No GitHub token specified" and a note that a token must be provided via the GH_TOKEN or GITHUB_TOKEN environment variable.

semantic-release
[semantic-release] > ENOGHTOKEN No GitHub token specified.
A GitHub token must be created and set in the GH_TOKEN or GITHUB_TOKEN environment variable
on your CI environment.

Common causes

The token was never passed into the step env

The secret exists but the semantic-release step has no env: mapping, so the plugin sees an empty environment and cannot authenticate.

A typo in the environment variable name

The variable was named GH_TOKEN_ or GITHUB-TOKEN, so the exact names the plugin reads are still unset.

How to fix it

Expose the token in the release step

  1. Map the automatic token into the step as GITHUB_TOKEN.
  2. Confirm the name matches exactly (GH_TOKEN or GITHUB_TOKEN).
  3. Re-run so the github plugin can read it.
.github/workflows/release.yml
- run: npx semantic-release
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Use a stored PAT when the default token is not enough

For protected branches or cross-repo releases, store a PAT and pass it as GH_TOKEN.

.github/workflows/release.yml
env:
  GH_TOKEN: ${{ secrets.RELEASE_TOKEN }}

How to prevent it

  • Always add an env: block to the semantic-release step.
  • Use the exact names GH_TOKEN or GITHUB_TOKEN, not variants.
  • Keep tokens in CI secrets, never inline in the workflow.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →