API returns 400 "Invalid project ids or slugs" for valid project - started suddenly

[melv-n]

CLI Version

3.0.0

Operating System and Architecture

• macOS (arm64)
• macOS (x86_64)
• Linux (i686)
• Linux (x86_64)
• Linux (armv7)
• Linux (aarch64)
• Windows (i686)
• Windows (x86_64)

Operating System Version

Linux Cloud Build container

Link to reproduction repository

No response

CLI Command

sentry-cli releases new

Exact Reproduction Steps

Description

Our CI pipeline suddenly started failing with "Invalid project ids or slugs" when creating releases. No configuration changes were made - this has been working
reliably for weeks and started failing today (2025-12-15).

Steps to Reproduce

SENTRY_ORG=my-org \
SENTRY_PROJECT=app-production \
SENTRY_AUTH_TOKEN=<token> \
sentry-cli releases new <commit-sha>

Expected Results

It works.

Actual Results

error: API request failed

Caused by:
    sentry reported an error: request failure (http status: 400)
      Object {"projects": Array [String("Invalid project ids or slugs")]}

Logs

  docker.io/getsentry/sentry-cli:latest
    DEBUG   2025-12-15 17:02:08.435032802 +00:00 sentry-cli version: 3.0.0, platform: "linux", architecture: "x86_64"
    INFO    2025-12-15 17:02:08.436788753 +00:00 sentry-cli was invoked with the following command line: "/bin/sentry-cli" "--log-level" "debug" "releases" "new" 
  "6643db261a56917ab2024e396b2b52342b890bb7"
    DEBUG   2025-12-15 17:02:08.437910697 +00:00 using token authentication
    DEBUG   2025-12-15 17:02:08.437951316 +00:00 json body: 
  {"version":"6643db261a56917ab2024e396b2b52342b890bb7","projects":["sms-production"],"dateStarted":"2025-12-15T17:02:08.437836534Z"}
    DEBUG   2025-12-15 17:02:08.437994120 +00:00 retry number 0, max retries: 5
    DEBUG   2025-12-15 17:02:08.478875598 +00:00 > POST /api/0/organizations/syb/releases/ HTTP/1.1
    DEBUG   2025-12-15 17:02:08.478936043 +00:00 > Host: sentry.io
    DEBUG   2025-12-15 17:02:08.478944204 +00:00 > Accept: */*
    DEBUG   2025-12-15 17:02:08.478950961 +00:00 > Connection: TE
    DEBUG   2025-12-15 17:02:08.478956977 +00:00 > TE: gsyzip
    DEBUG   2025-12-15 17:02:08.478965300 +00:00 > User-Agent: sentry-cli/3.0.0
    DEBUG   2025-12-15 17:02:08.479728016 +00:00 > Authorization: Bearer <REDACTED>
    DEBUG   2025-12-15 17:02:08.479763472 +00:00 > Content-Type: application/json
    DEBUG   2025-12-15 17:02:08.479773515 +00:00 > Content-Length: 131
    DEBUG   2025-12-15 17:02:08.718853507 +00:00 < HTTP/1.1 400 Bad Request
    DEBUG   2025-12-15 17:02:08.718909961 +00:00 < server: nginx
    DEBUG   2025-12-15 17:02:08.718921391 +00:00 < date: Mon, 15 Dec 2025 17:02:07 GMT
    DEBUG   2025-12-15 17:02:08.718933084 +00:00 < content-type: application/json
    DEBUG   2025-12-15 17:02:08.718941254 +00:00 < allow: GET, POST, HEAD, OPTIONS
    DEBUG   2025-12-15 17:02:08.718950043 +00:00 < access-control-allow-methods: GET, POST, HEAD, OPTIONS
    DEBUG   2025-12-15 17:02:08.718974290 +00:00 < access-control-allow-headers: X-Sentry-Auth, X-Requested-With, Origin, Accept, Content-Type, Authentication, 
  Authorization, Content-Encoding, sentry-trace, baggage, X-CSRFToken
    DEBUG   2025-12-15 17:02:08.718983562 +00:00 < access-control-expose-headers: X-Sentry-Error, X-Sentry-Direct-Hit, X-Hits, X-Max-Hits, Endpoint, Retry-After, 
  Link
    DEBUG   2025-12-15 17:02:08.718993005 +00:00 < access-control-allow-origin: *
    DEBUG   2025-12-15 17:02:08.719001860 +00:00 < x-sentry-rate-limit-remaining: 39
    DEBUG   2025-12-15 17:02:08.719010654 +00:00 < x-sentry-rate-limit-limit: 40
    DEBUG   2025-12-15 17:02:08.719018945 +00:00 < x-sentry-rate-limit-reset: 1765818128
    DEBUG   2025-12-15 17:02:08.719027933 +00:00 < x-sentry-rate-limit-concurrentremaining: 24
    DEBUG   2025-12-15 17:02:08.719036115 +00:00 < x-sentry-rate-limit-concurrentlimit: 25
    DEBUG   2025-12-15 17:02:08.719045230 +00:00 < vary: Cookie, Accept-Language
    DEBUG   2025-12-15 17:02:08.719054152 +00:00 < x-frame-options: deny
    DEBUG   2025-12-15 17:02:08.719063242 +00:00 < x-content-type-options: nosniff
    DEBUG   2025-12-15 17:02:08.719071130 +00:00 < x-xss-protection: 1; mode=block
    DEBUG   2025-12-15 17:02:08.719272619 +00:00 body: {"projects":["Invalid project ids or slugs"]}
  error: API request failed

  Caused by:
      sentry reported an error: request failure (http status: 400)
        Object {"projects": Array [String("Invalid project ids or slugs")]}

[linear]

CLI-250

ENG-6160

[szokeasaurusrex]

Hi @melv-n, thanks for reporting this issue. We released Sentry CLI 3.0.0 today (about six hours ago) so that might be the cause.

I'll investigate. Please pin the previous version, 2.58.4, in the meantime, as a workaround.

[melv-n]

Hi @melv-n, thanks for reporting this issue. We released Sentry CLI 3.0.0 today (about six hours ago) so that might be the cause.

I'll investigate. Please pin the previous version, 2.58.4, in the meantime, as a workaround.

Thanks, reverting to the previous version works 👍

[szokeasaurusrex]

Hi @melv-n and @adnweedon, after some more investigation, I have identified the root cause of this behavior.

Specifically, Sentry CLI 3.0.0 now creates releases using a newer API endpoint. It seems that this new endpoint only allows users to create releases for projects which they are members of; I think this restriction is itself the underlying bug, since the restriction is not present on the still available legacy API endpoint that Sentry CLI 2.x and older were using. The error you are observing is raised when you hit this supposed permissions error.

I am going to transfer this issue to the backend's repo, since it makes more sense to fix this bug in the backend than the CLI.

My recommendation for you

This permissions error should only occur if you are using a Personal Token; however, for security reasons, we recommend avoiding personal tokens in CI environments.

Therefore, I would recommend you reconfigure your CI environment to use an Organization Token, instead. These tokens are specifically designed to be used in CI environments, and should have the permissions to create releases for any projects in your org. Switching to an org token is both best practice security-wise and should also allow you to work around this bug.